Cervantiq is a dental practice management system I built for my wife's dental clinics. The goal: a production-grade platform that stays within startup budget constraints — no NAT Gateways, no expensive always-on compute, and no compromises on security or scalability.
Design Principles
- Serverless-first. Pay only for what you use. Lambda for compute, RDS for persistence, S3 for storage.
- Event-driven. Decouple processes like email dispatch, push notifications, and image processing using S3 event triggers.
- No NAT Gateway. At ~$32/month per AZ before data processing charges, NAT Gateways are a startup killer. The architecture is designed to avoid them entirely.
- Managed services over self-hosted. SES for email, CloudFront for CDN, WAF for edge protection — let AWS handle the undifferentiated heavy lifting.
The No-NAT Gateway Strategy
This is the architectural decision that shapes everything else. The conventional wisdom says VPC Lambdas need a NAT Gateway to reach AWS services. That's true for most service endpoints — but not for S3.
The S3 Gateway Endpoint is free, doesn't require a NAT Gateway, and provides private connectivity from VPC resources to S3. By making S3 the coordination layer for event-driven workflows, VPC Lambdas can trigger non-VPC Lambdas without ever needing internet access.
How it works
- The API Lambda (Rust/GraphQL, running inside the VPC for RDS access) writes event job files to an Events Bucket via the S3 Gateway Endpoint.
- S3 event notifications trigger non-VPC Lambdas (email dispatch, thumbnail generation) that have direct access to SES, SNS, and other AWS services — no NAT needed.
- Non-VPC Lambdas read the job payload from S3, execute the work, and write results back to S3 if needed.
This pattern effectively distributes processes across VPC and non-VPC boundaries using S3 as the bridge — all without NAT Gateways or VPC Endpoints for other services.
Architecture Layers
Edge & CDN
- Route 53 — DNS for all subdomains (app, api, assets, patient-assets)
- AWS WAF — Web ACLs on the frontend CDN, patient assets CDN, and API Gateway
- CloudFront — Three distributions: frontend app (geo-restricted to PH), public assets (no WAF, static content), and patient assets (signed cookies for PHI access)
API Layer
- HTTP API Gateway — Routes requests to the VPC-attached API Lambda and the non-VPC patient assets cookie signer
- API Lambda (Rust/GraphQL) — The core application logic, running inside the VPC for direct RDS connectivity
VPC Design
- CIDR: 10.1.0.0/23 — Small, right-sized for the workload
- 3 AZs — Public subnets (bastion, currently disabled) and private subnets (API Lambda, RDS)
- S3 Gateway Endpoint — The key enabler for NAT-free operation
- RDS PostgreSQL 16 on db.t4g.micro — right-sized for early-stage traffic
Event-Driven Workflows
- Email dispatch: API Lambda writes a job to the Events Bucket → S3 triggers the Mailer Lambda → Mailer reads the job and sends via SES
- Avatar thumbnails: Upload lands in the Public Assets or Patient Files bucket → S3 triggers the Thumbnail Generator Lambda → resized image written back to S3
- Bounce handling: SES publishes bounce/complaint events to SNS → SNS triggers the Bounce Handler Lambda (VPC) → updates the user record in RDS
Data Compliance
- Patient Records Bucket — PHI data accessed only through signed CloudFront cookies
- Retention Lambda — Enforces DPA (Data Privacy Act) compliance by managing data lifecycle
- SSM Parameter Store — Secrets management for API keys, DB credentials, and signing keys
Cost Profile
With this architecture, the monthly baseline cost for a low-traffic dental clinic is remarkably low:
- RDS db.t4g.micro — ~$13/month (the single biggest line item)
- Lambda — effectively free at low volumes (generous free tier)
- S3 + CloudFront — pennies for a single-clinic app
- NAT Gateway — $0 (that's the point)
Compare this to a traditional architecture with NAT Gateways across 3 AZs: that alone would be ~$96/month before any data processing — more than the entire rest of the infrastructure combined.
Trade-offs
This design isn't free of trade-offs:
- VPC Lambdas can't call most AWS APIs directly. They can only reach S3 (via Gateway Endpoint) and RDS. Any other AWS service interaction must be delegated to non-VPC Lambdas via the S3 event pattern.
- Added latency for event-driven flows. S3 event notifications add a small delay (typically <1s) compared to direct invocation. Acceptable for email and thumbnails, but not for synchronous user-facing operations.
- Operational complexity. Debugging distributed event-driven flows requires good observability. CloudWatch Logs and X-Ray tracing are essential.
Infrastructure as Code
The entire stack is managed with Terraform, organized by environment. This makes it straightforward to spin up additional environments (staging, production) or replicate the architecture for another clinic.
TL;DR
Cervantiq proves you can build a secure, scalable, production-grade SaaS on AWS without NAT Gateways. The key insight: use the free S3 Gateway Endpoint as your coordination layer between VPC and non-VPC workloads. Let S3 event triggers bridge the gap, and keep expensive always-on infrastructure out of the picture entirely.
Built this for my wife's dental clinic. Turns out "startup-friendly" and "enterprise-grade" aren't mutually exclusive — you just have to be intentional about where the money goes.