From Zero Cloud Infrastructure to a Production AWS Environment

From Zero Cloud Infrastructure to a Production AWS Environment

Industry: Healthcare 
Location: United States 
Client since: 2026
0% to 100% automated release coverage
No established environment to full production on a 0.25 FTE DevOps capacity
0 to 14 live production services
Technologies used
Healthcare

Background 

Millions of working adults quietly run a second job: coordinating care for an aging parent. The scheduling, the transport, and the daily check-ins land in the middle of the workday, and employers have started treating that load as a benefits question rather than a private one. Software that takes it on has to handle voice interaction, third-party logistics, and health-adjacent personal data at the same time. For an early-stage product, that combination raises the bar on infrastructure long before the first user signs in.

Challenge 

The product itself existed only as a prototype, with no real cloud infrastructure behind it. There was no environment separation, no security hardening, no CI/CD, and no observability. The workload also ruled out the obvious low-cost answer: long-running webhook callbacks from a third-party voice AI vendor, scheduled background jobs, and a need for persistent database connections. Choosing the wrong hosting model would surface as cold starts and timeouts once real users arrived, and there was no in-house DevOps team to weigh those trade-offs or to run the result afterwards. 

The work needed to cover: 

  • A production-capable AWS environment, built from zero 
  • Environment separation and security hardening 
  • CI/CD pipelines for both the API and the frontend 
  • Observability that could trace a single request end to end
  • A hosting model suited to long-running callbacks and scheduled jobs 
  • Authentication for enterprise and individual users
  • Notifications, asynchronous processing, and scheduled job handling 
  • Payments and ride-ordering integrations
  • Four core modules taken to QA-passed, cutover-ready state
  • All of it without the client hiring an in-house DevOps function

Solution

We ran the engagement architecture-first, then build. Infrastructure was treated as the first phase of delivery rather than something to catch up on later, which meant the AWS foundation was provisioned, secured, and CI/CD-enabled before any application feature work started.

1. A hosting model chosen against the actual workload 

We evaluated AWS Lambda against ECS Fargate for the backend, judged on how the product actually behaves rather than on a default. Lambda’s execution time limit and cold starts were a poor fit for long-running vendor callbacks and persistent database connections, so we chose Fargate. At pilot scale the difference came to roughly 15 to 45 USD per month, a marginal cost against the reliability it bought.

hosting-model-chosen-against-the actual-workload

2. A production AWS foundation from zero 

We stood up the full environment: a VPC, an Application Load Balancer fronted by WAF, ECS Fargate for the API, S3 and CloudFront for the frontend, and PostgreSQL on Amazon RDS. A single Amazon Cognito user pool handles authentication. EventBridge and SQS carry scheduled and asynchronous jobs, and SES and SNS handle notifications.

3. Automated delivery from day one 

Pipelines for the API and the frontend were built in that same first phase, before there were features to deploy through them. Every change since has gone out the same way, so releases were safe and repeatable from the start rather than retrofitted once the codebase had grown.

4. Observability and security, with cost held in view 

We designed a structured logging strategy in CloudWatch built on correlation IDs, so a single request can be traced end to end across services. We also made a deliberate call to skip AWS OpenSearch for the pilot, since CloudWatch Logs Insights alongside the relational database covered the real reporting and audit needs at a fraction of the cost. Security was hardened in the same phase rather than after it. 

DWEL DWEL

Automated pipelines, hardened
infrastructure, from day one.

Key technical implementations

  • WAF rules applied at the load balancer
  • Least-privilege IAM roles per service 
  • Secrets held in AWS Secrets Manager
  • Encryption at rest and in transit 
  • Correlation ID based request tracing in CloudWatch
  • CloudWatch alarms and dashboards 
  • Route 53 for DNS 
  • Stripe for payments, Uber API for ride orchestration
  • A mock voice service standing in for the vendor integration during development 

One part-time DevOps engineer, at 25 percent allocation, owned infrastructure, CI/CD, monitoring, and deployment automation across the whole engagement. Embedding that role inside the delivery team, rather than running it as a separate workstream, is what let the client reach a pilot-ready environment without standing up an in-house DevOps function.

Results

Four core modules went from architecture proposal to QA-passed, cutover-ready MVP in about five months, between March and September 2026. The AWS environment behind them was complete and automated before the first feature shipped. 

Delivery automation 

  • Automated release coverage rose from 0 percent to 100 percent, across both the API and the frontend 
  • Pipelines were operational in the engagement’s first phase, before any feature work began 
  • Every API and frontend release since has gone through the same automated path

Infrastructure

  • 14 production AWS services went live from a starting point of none
  • Network, compute, database, authentication, security, and CI/CD were all provisioned and hardened ahead of feature delivery
  • Secrets management, CloudWatch alarms, and dashboards were completed as the pilot approached go-live 

Reliability and cost 

  • No infrastructure-related blocking incidents occurred through MVP cutover readiness 
  • Open items at cutover readiness were all application-level, a payment retry path and a reporting screen, rather than infrastructure gaps 
  • A quarter-time DevOps allocation covered the entire pilot environment, so no in-house DevOps hires were needed 

The largest risk to the timeline sat outside our control. The third-party voice API contract was not finalized when architecture work began, so rather than wait on it, we specified the expected contract upfront and built a mock voice service against it. 

DWEL DWEL

Build and operate your AWS infrastructure
without hiring an in-house team.

Share
You might be interested
Accelerating MVP for a COVID-19 Testing App on AWS
Healthcare
Accelerating MVP for a COVID-19 Testing App on AWS
Creating Secure AWS VPN with Hybrid Cloud Auth for SAP
IT
Creating Secure AWS VPN with Hybrid Cloud Auth for SAP
Leveraging Serverless Capabilities to Build a Mental Health Application
Healthcare Mental Health
Leveraging Serverless Capabilities to Build a Mental Health Application