From Cloud Dependency to Full Infrastructure Ownership

At a Glance

Client

Woogway — technology company, Japan

Challenge

Migrate 50 production API services from AWS to self-managed on-prem infrastructure

Outcome

Full migration completed in 13 weeks; ~65% reduction in infrastructure costs; zero service interruptions

Technologies Replaced

AWS Lambda, API Gateway, Aurora PostgreSQL, Cognito

Technologies Deployed

Apache OpenWhisk, Keycloak, PostgreSQL (on-prem), Express.js middleware

Engagement Type

Architecture design, migration execution, production cutover

Woogway is a technology company based in Japan, building and operating a portfolio of internal tooling and customer-facing digital platforms for enterprise clients. At the time of engagement, the organisation employed a mid-sized engineering team and operated approximately 50 API services in production — covering authentication flows, data retrieval, business logic, and integration with third-party platforms. The entire stack had been hosted on AWS since the company's founding, using a fully managed architecture built around Lambda functions, API Gateway, Aurora PostgreSQL Serverless, and Cognito.

By late 2023, several pressures had converged. AWS spend had scaled beyond what the team's usage patterns warranted — managed services carry a premium that makes sense at early scale but becomes hard to justify once the organisation has the engineering maturity to operate its own infrastructure. A separate concern, and one with harder edges, was data sovereignty. Internal policy reviews triggered by evolving regulatory guidance in Japan's digital services sector had identified that hosting sensitive operational data on third-party cloud infrastructure without documented repatriation capability was a risk the organisation was no longer willing to carry. The final pressure was more operational: the team had limited observability into infrastructure behaviour because so much of it was abstracted away by AWS. When something behaved unexpectedly, the diagnostic trail often ran cold at the managed-service boundary.

These three things — cost, sovereignty, and control — formed the mandate for the project. The requirement was not merely to reduce cloud spend. It was to own the infrastructure entirely.

What the existing architecture looked like

The production stack was fully managed: Lambda handled all compute, API Gateway managed routing and rate limiting, Aurora PostgreSQL Serverless handled all persistent data, and Cognito managed authentication and token issuance. From the outside, this architecture had been frictionless to operate — AWS abstracted the underlying complexity entirely. But it also meant that the team had never had to build, configure, or maintain the infrastructure layer themselves.

Fifty functions were in production. They ranged from lightweight data-retrieval endpoints returning sub-millisecond responses to heavier processing jobs. All of them were invoked through API Gateway, authenticated via Cognito tokens, and persisted data to Aurora. The React-based frontend communicated with these APIs over the public internet, routed through AWS's managed edge network.

Why previous attempts had stalled

The team had evaluated an on-premises migration once before, approximately 18 months prior. That evaluation had stalled for two reasons. First, the choice of API gateway software had been contentious — Kong was the preferred candidate, but standing up Kong in an on-premises environment requires a separate database, migration scripts, service and route configuration, and plugin management. The overhead was sufficient to make the project feel more complicated than the team wanted to take on alongside a full product roadmap. Second, the SSL story for a private LAN without a public domain was unresolved — the team was not confident about how to handle certificate distribution and browser trust on a closed network.

Those two problems were still in play when the project was re-scoped for 2024. Aarya Global was brought in precisely because both had tractable solutions that the team had not yet landed on.

The core difficulty was not the migration itself — it was the series of infrastructure decisions that had to be made correctly before a single function could be moved. Wrong choices at the gateway or authentication layer would have required rework of all 50 services.

Phase 1 — Architecture Design and Stack Selection (January 2024)

The first four weeks were spent on architecture design and stack selection. This phase was deliberately front-loaded with the harder decisions, so that the migration phases that followed could proceed with confidence.

The first major decision was the API gateway. Aarya Global evaluated Kong alongside the built-in API gateway provided by Apache OpenWhisk — the serverless runtime selected to replace Lambda. The evaluation surfaced a clear trade-off: Kong offers more advanced features (rate limiting, analytics, plugin ecosystem), but its operational overhead in an on-premises context is substantially higher. For 50 functions on a private LAN, with no public-facing traffic patterns to manage, that overhead was not justified. The OpenWhisk built-in gateway eliminated a separate service, leveraged native action integration, and reduced the operational surface area of the deployment. Kong was set aside with a documented recommendation to revisit it when the API footprint grows beyond approximately 100 functions.

The second major decision was SSL. Since no public domain was involved, a CA-signed certificate from a public authority was not the right tool. Aarya Global generated a self-signed certificate and private key using OpenSSL, distributed it across all LAN machines, and installed it in the Windows Trusted Root Certificate Store on client devices. Node.js was configured to trust the local CA via the NODE_EXTRA_CA_CERTS environment variable. This gave the organisation a working HTTPS setup across the internal network without requiring any external certificate authority.

The third architectural challenge was the React frontend's CORS exposure. The browser's Same-Origin Policy blocked direct cross-origin API calls from the frontend to OpenWhisk. Rather than trying to configure CORS permissively on the OpenWhisk side — which would have created security considerations — Aarya Global introduced an Express.js middleware proxy running on the same origin as the React application. The proxy receives browser requests (same-origin, no CORS block), attaches Keycloak authentication tokens server-side, and forwards them to OpenWhisk via server-to-server calls that are not subject to the Same-Origin Policy. This pattern cleanly separated the browser's security context from the API layer.

Phase 2 — Migration Execution (February 2024)

With the architecture settled, February was spent on migration execution. The PostgreSQL database was provisioned on-premises and the Aurora schemas and data were migrated first — establishing the data layer as a stable foundation before any compute was moved. Keycloak was stood up and configured as a drop-in replacement for Cognito, with token issuance and validation wired through the Express.js middleware. The OpenWhisk runtime was deployed and configured, and the 50 Lambda functions were ported to OpenWhisk actions. The porting work was systematic: function by function, with equivalence tests run against each one in a staging environment before being marked migration-complete.

Phase 3 — Testing and Cutover (March 2024)

March was allocated to end-to-end integration testing, performance validation, and the production cutover. Each of the 50 API functions was tested against the production data snapshot for functional equivalence. Load testing was run across the stack to confirm that the OpenWhisk runtime and the PostgreSQL instance behaved stably under realistic traffic. The cutover itself was executed during a pre-planned low-traffic window, with DNS and routing changes applied progressively. No service interruptions were recorded during the transition period.

Cost

Monthly infrastructure costs dropped by approximately 65% following the migration. The majority of the reduction came from eliminating managed-service fees for Lambda, API Gateway, and Aurora Serverless — the most expensive line items in the previous AWS bill. The remaining on-premises costs are dominated by fixed hardware depreciation and electricity, which do not scale with API traffic.

Performance

API response times on the internal network improved materially. Calls that previously routed over the public internet through AWS's managed edge averaged 150–180 ms. On the private LAN, those same calls now average under 40 ms. For the company's internal tooling workflows — where users were making multiple sequential API calls per action — this improvement was immediately perceptible.

Data Sovereignty

All operational data now resides on hardware owned and operated by Woogway. There is no ongoing dependency on any cloud vendor for the API platform. The organisation can demonstrate to auditors and regulators that sensitive data does not leave its physical premises. The compliance posture concern that had been flagged in the 2023 policy review was fully resolved.

Operational Visibility

With the infrastructure now self-managed, the engineering team has full visibility into the behaviour of every layer — from network requests to database queries to function execution logs. Diagnostic investigations that previously ran cold at the AWS managed-service boundary are now fully traceable end to end.

Unexpected Benefit: Frontend Performance

A benefit that had not been explicitly planned for was the improvement in frontend performance for users on the internal network. Because the React application and the API layer now share the same LAN, page load times that involve multiple API calls dropped by roughly 60–70% for internal users. This was a direct consequence of removing the cloud routing hop — not something that had been modelled in the original business case, but one that became immediately visible to end users after the migration.

“

“We had been putting this off for two years because the complexity felt too high. Aarya Global made it straightforward — the whole stack moved without disrupting a single production service.”

“

“The two things that had blocked us before — the API gateway choice and the SSL story on a private network — both turned out to have clean solutions. We just hadn't landed on them ourselves. Once those were decided, the rest of the migration ran like a normal deployment cycle.”

Following the successful cutover, Aarya Global and Woogway have continued working together on the next phase of infrastructure hardening. Current work includes implementing an internal certificate authority using Smallstep Step CA to replace the self-signed certificate approach with automated issuance and renewal, and building a CI/CD pipeline for OpenWhisk function deployments to reduce manual deployment steps and introduce a proper audit trail for production changes.

A longer-term evaluation of Kong or APISIX as the API gateway — as the function footprint grows beyond 50 — is also in scoping. The migration provided the clean foundation from which that kind of deliberate, incremental evolution is now possible.

Whether the driver is cost, sovereignty, or operational control — we're happy to share how we approached this migration and whether a similar model could apply to your environment.