How Webskyne Achieved 40% Cost Savings and 3x Performance Gains with a Serverless Architecture

# How Webskyne Achieved 40% Cost Savings and 3x Performance Gains with a Serverless Architecture ## Overview Webskyne is a fast-growing SaaS provider offering project management and collaboration tools to mid-sized enterprises. By early 2025, the platform served over 150,000 active users across 3,000 organizations. The legacy architecture relied on a monolithic Node.js application hosted on traditional EC2 instances behind an Elastic Load Balancer. While the monolith enabled rapid feature development initially, it began to show signs of strain: scaling was coarse-grained, deployments carried risk of system-wide downtime, and infrastructure costs were rising linearly with user growth. The engineering leadership set a bold target: reduce infrastructure costs by at least 30% while improving page load times by 50% and enabling near‑instantaneous horizontal scaling to handle unpredictable traffic spikes. After evaluating containers, platform‑as‑a‑service, and function‑as‑a‑service options, the team chose a serverless approach using AWS Lambda, Amazon API Gateway, Amazon DynamoDB, and Amazon S3 for static assets. ## Challenge ### Performance Bottlenecks During peak usage (weekday mornings in the US and Europe), average page load times exceeded 4.2 seconds, with the homepage often taking over 6 seconds to become interactive. Profiling revealed that the monolith’s single-threaded request handling caused queue buildup under concurrent load, and the relational database (Amazon RDS PostgreSQL) struggled with connection pool exhaustion. ### Cost Inefficiencies The EC2 fleet was sized for peak capacity, resulting in average utilization of only 28% during off‑peak hours. Reserved instances helped, but the company still paid for idle compute. Additionally, each new feature required a full‑stack deployment, increasing the chance of regressions and lengthening release cycles to an average of two weeks. ### Operational Overhead Patch management, OS updates, and instance scaling activities consumed roughly 20% of the DevOps team’s capacity. Monitoring was fragmented across multiple tools, making root‑cause analysis slow. ### Scalability Limits The monolith could scale vertically only up to the limits of the largest EC2 instance type. Horizontal scaling required cloning the entire application, which wasted resources because only certain modules (e.g., real‑time notifications) experienced bursty demand. ## Goals 1. **Cost Reduction**: Cut monthly infrastructure spend by at least 30% within six months. 2. **Performance Improvement**: Reduce average page load time to under 2 seconds and achieve a 95th‑percentile response time below 1.5 seconds for API calls. 3. **Elastic Scaling**: Enable the system to handle traffic spikes of up to 10× baseline load without manual intervention. 4. **Deployment Agility**: Reduce release cycle time from two weeks to under two days, with the ability to roll back individual services independently. 5. **Operational Simplicity**: Decrease the operational overhead associated with server management by 50%. ## Approach The migration followed a strangler‑pattern strategy: new features and high‑traffic components were rebuilt as serverless functions, while the existing monolith continued to serve legacy routes. Over time, more functionality was shifted to the serverless side until the monolith was retired. ### Architecture Selection - **Compute**: AWS Lambda for backend logic, with Node.js 18 runtime. - **API Layer**: Amazon API Gateway (REST) to route requests to Lambda functions. - **Data Storage**: Amazon DynamoDB for user data, project metadata, and real‑time activity feeds; Amazon S3 for file uploads and static assets. - **Authentication**: Amazon Cognito User Pools and Identity Pools for secure sign‑in and JWT token handling. - **Observability**: AWS X‑Ray for distributed tracing, Amazon CloudWatch Logs and Metrics for monitoring, and AWS Lambda Insights for performance profiling. - **Infrastructure as Code**: AWS CDK (TypeScript) to define and version‑control all resources. ### Phased Migration Plan | Phase | Duration | Scope | Outcome | |-------|----------|-------|----------| | 1 | 6 weeks | User authentication and password reset flows | Migrated to Cognito + Lambda authorizers; decommissioned legacy auth tables | | 2 | 8 weeks | Project dashboard and listing APIs | Rebuilt dashboard microservice; switched read‑only traffic to Lambda/DynamoDB | | 3 | 10 weeks | Real‑time notifications and WebSocket fallback | Introduced API Gateway WebSocket API backed by Lambda; used DynamoDB Streams for fan‑out | | 4 | 8 weeks | File uploads and asset serving | Migrated to S3 with presigned URLs; Lambda for post‑processing (thumbnails, virus scan) | | 5 | 6 weeks | Billing and reporting | Created serverless billing microservice; migrated nightly aggregation jobs to Lambda + Step Functions | | 6 | 4 weeks | Monolith decommission | Retired EC2 instances; redirected all traffic to API Gateway | Each phase included feature flags, canary releases, and automated rollback triggers based on error rates and latency. ## Implementation ### Authentication Migration The legacy auth system used bcrypt‑hashed passwords stored in PostgreSQL. The team migrated user pools to Amazon Cognito, imported existing users via a Lambda‑based migration script that verified hashes during first sign‑in, and then migrated them to Cognito’s secure storage. API Gateway Lambda authorizers validated JWTs for protected routes. ### Dashboard Service The dashboard Lambda function fetches a user’s projects from DynamoDB using a composite partition key (userId#project) and a sort key for metadata. To avoid hot partitions, the team added a random suffix to the partition key for write‑heavy activities (e.g., activity logs) and used DynamoDB Accelerator (DAX) for read‑heavy dashboard queries. ### Real‑Time Notifications Instead of maintaining persistent WebSocket connections on EC2, the team used API Gateway WebSocket routes. Connection management Lambda functions stored connection IDs in DynamoDB with a TTL of 24 hours. When a notification event occurred (via DynamoDB Streams from project updates), a fan‑out Lambda fetched the list of affected connections and pushed messages via the API Gateway Management API. ### File Uploads Clients now request a presigned PUT URL from an upload Lambda function, which signs an S3 object key with appropriate metadata and ACLs. After upload completes, S3 triggers an ObjectCreated event that invokes a processing Lambda to generate thumbnails, scan for malware, and update the file record in DynamoDB. ### Infrastructure as Code The entire architecture was defined in a monorepo using AWS CDK. Each microservice had its own CDK construct, allowing independent versioning. Pipeline stages ran unit tests, integration tests against a local DynamoDB instance (via Docker), and synthetic load tests using AWS Lambda PowerTools. ### Observability AWS X‑Ray was enabled for all Lambda functions and API Gateway stages. Custom annotations captured business context (userId, projectId). CloudWatch Alarms triggered on error rates >1% or latency >2 seconds for 5‑minute periods, prompting automated SNS notifications to the on‑call engineer. ## Results ### Cost Savings After completing all six phases and decommissioning the EC2 fleet, Webskyne’s monthly AWS bill dropped from $18,400 to $11,040—a 40% reduction. The serverless model’s pay‑per‑use pricing meant that during nights and weekends, costs fell to near‑zero for idle functions, while peak‑hour spending aligned closely with actual request volume. ### Performance Improvements - **Average page load time**: decreased from 4.2 seconds to 1.3 seconds (69% faster). - **API 95th‑percentile latency**: dropped from 2.8 seconds to 0.9 seconds (68% faster). - **Time to first byte (TTFB)**: improved from 1.1 seconds to 0.3 seconds. These gains were measured using Web Vitals collected from real‑user monitoring (RUM) via Amazon CloudWatch RUM. ### Scalability During a promotional campaign that drove a 9× surge in sign‑up requests, the system automatically scaled to handle 14,000 concurrent Lambda invocations without errors or latency degradation. The previous architecture would have required manual EC2 scaling and risked overload. ### Deployment Agility The average release cycle dropped from 14 days to 1.8 days. Teams could deploy individual microservices independently, reducing the blast radius of faulty releases. Mean time to recover (MTTR) from a bad release fell from 4.5 hours to 22 minutes thanks to instant rollback via alias updates in Lambda. ### Operational Overhead The DevOps team reported a 55% reduction in time spent on patching, OS upgrades, and instance scaling activities. Alert fatigue decreased by 40% due to more precise, service‑level alarms. ## Key Metrics | Metric | Before Migration | After Migration | Improvement | |--------|------------------|-----------------|-------------| | Monthly Infrastructure Cost | $18,400 | $11,040 | -40% | | Average Page Load Time | 4.2s | 1.3s | -69% | | API 95th‑pct Latency | 2.8s | 0.9s | -68% | | Release Cycle Time | 14 days | 1.8 days | -87% | | MTTR (bad release) | 4.5h | 0.37h | -92% | | DevOps Ops Time (weekly) | 20 hrs | 9 hrs | -55% | | Peak Concurrent Users Handled | 1,500 (manual scale) | 14,000 (auto) | +833% | | Error Rate (5xx) | 0.8% | 0.12% | -85% | ## Lessons Learned 1. **Invest in Observability Early** – Distributed tracing and structured logging were indispensable for debugging cross‑service issues. Retrofitting observability later would have been far more costly. 2. **Design for Idempotency** – Lambda functions can be retried; ensuring idempotent operations prevented duplicate charges or double‑booked resources. 3. **Watch for Third‑Party Limits** – Early in the migration, the team hit DynamoDB throttling on a hot partition; redesigning keys and using DAX resolved the issue. 4. **Feature Flags Are Essential** – Gradual rollout with kill switches allowed safe experimentation and quick rollback when unexpected behavior surfaced. 5. **Team Upskilling Pays Off** – Investing time in Lambda‑specific patterns (e.g., async initialization, lazy loading of SDK clients) paid dividends in performance and cost. 6. **Cold Start Mitigation Matters** – For latency‑critical endpoints, the team used provisioned concurrency on high‑traffic functions and kept initialization lightweight. 7. **Measure, Don’t Guess** – Continuous monitoring of cost and performance metrics guided each migration phase and justified further investment. ## Conclusion Webskyne’s migration to a serverless architecture demonstrates how a thoughtful, incremental approach can yield substantial cost savings, performance gains, and operational agility. By aligning technology choices with business goals—reducing waste, improving user experience, and enabling rapid innovation—the company not only cut its infrastructure bill by 40% but also positioned itself for scalable growth in the years ahead.  *The diagram above illustrates the core components of Webskyne’s serverless setup: API Gateway routing to Lambda functions, backed by DynamoDB and S3, with Cognito handling authentication.* --- *Author: Webskyne editorial* *Published: May 28, 2026* *Tags: serverless, AWS Lambda, API Gateway, cost optimization, performance engineering, migration case study, cloud architecture*