Architecture that serves
business. Nothing more.
The following case studies illustrate how Denvan approaches complex cloud challenges, from the initial business question through architectural design, trade-off decisions, and outcome framing. Each is a representative architecture, not a client disclosure.
A note on methodology: Denvan does not disclose client names, proprietary data, or confidential business outcomes without explicit consent. The architectures presented here are representative implementations, developed to illustrate how we think through specific classes of problem. They reflect real architectural patterns, real trade-off reasoning, and real design decisions. They do not represent the specific circumstances of any named organization.
Where we label something a Reference Implementation, the architectural pattern has been validated through industry practice. Where we label it a Technical Demonstration, the design is intended to show capability and approach rather than a deployed solution.
Unified Patient Data Platform
on AWS HealthLake
"We operate across fourteen facilities. Patient data lives in six separate systems. Our compliance team spends 120 hours a month pulling audit reports manually, and we still have gaps. We need a single source of truth, and we need it to be HIPAA-compliant from the ground up."
Context
A regional health network operating 14 facilities had accumulated six distinct clinical and administrative systems through years of acquisitions and organic growth. The systems (EHR, billing, laboratory, imaging, pharmacy, and scheduling) shared no common patient identifier. Each generated its own audit trail in its own format.
- No unified patient identifier across systems
- HIPAA audit trail incomplete and non-queryable
- PII scattered across unencrypted S3 buckets created by legacy migration scripts
- IAM roles with wildcard permissions inherited from early cloud lift-and-shift
- Compliance reporting consumed significant clinical staff time monthly
Discovery
A three-week architecture assessment identified four root causes: the absence of an event-driven integration layer meant each system was coupled directly to others; there was no canonical data model defining what a "patient record" meant across the organization; encryption was inconsistent and unmanaged; and IAM had grown organically with no governance structure.
The discovery also surfaced an opportunity: AWS HealthLake, a HIPAA-eligible FHIR R4 data store, could serve as the canonical patient data layer if the organization was willing to standardize on FHIR as its data exchange format.
Architectural Approach
The architecture establishes AWS HealthLake as the canonical FHIR R4 patient data store, with an EventBridge-driven integration layer that decouples all six legacy systems. Each system publishes events to EventBridge; a Lambda transform layer converts proprietary formats to FHIR R4 resources before writing to HealthLake. Aurora PostgreSQL handles operational transactional data. All inter-service communication occurs over PrivateLink; no traffic traverses the public internet. API Gateway and CloudFront provide the delivery layer for clinical applications, with all responses passing through KMS-encrypted channels.
Key Design Decisions
- FHIR R4 as the canonical data model, future-proofing integration with new EHR vendors and national health exchange standards
- Customer-managed KMS keys over AWS-managed, giving the organization key rotation control required under their HIPAA policy
- Multi-AZ Aurora over single-AZ RDS: RPO of ~1 minute, RTO of ~30 seconds for critical operational data
- EventBridge over direct API coupling; any legacy system can be replaced without modifying downstream consumers
- Private subnets only, no internet gateway, eliminating an entire category of network-layer attack surface
Trade-offs Accepted
- FHIR transformation latency (50–100ms per event) vs. direct database queries, accepted for standards compliance and long-term interoperability
- Customer-managed KMS overhead: key rotation, policy management, and break-glass procedures add operational complexity, accepted for regulatory control
- EventBridge cost at scale: offset by elimination of brittle point-to-point integrations and their maintenance burden
- HealthLake query latency vs. native EHR query, accepted because cross-system analytics was the primary use case, not real-time clinical lookup
Engagement Highlights
Security
All data encrypted at rest with customer-managed KMS keys. No public subnets. PrivateLink for all AWS service access. Macie scans for PII drift. GuardDuty for threat detection. CloudTrail provides complete, immutable audit trail. HIPAA BAA with AWS. IAM least-privilege enforced via permission boundaries.
Scalability
HealthLake scales horizontally without provisioning. EventBridge handles millions of events per day without infrastructure management. Aurora read replicas serve analytics workloads without contending with operational writes. Lambda concurrency controls prevent runaway event storms during peak clinical hours.
Cost Optimization
Reserved instances for Aurora (estimated 40% vs. on-demand for predictable workloads). S3 Intelligent-Tiering for historical FHIR documents. Lambda pricing (pay-per-invocation) eliminates always-on servers for event processing. CloudFront caching reduces origin requests for static clinical reference data.
This architecture provides a unified, HIPAA-eligible patient data platform capable of serving a multi-facility health network. The FHIR R4 data model eliminates the translation burden between systems and positions the organization for national health exchange participation. Automated CloudTrail audit trails replace manual compliance reporting. Eliminating public internet exposure for all patient data services substantially reduces the attack surface. The EventBridge integration layer allows any legacy system to be replaced independently without requiring a coordinated platform migration.
Lessons Learned
FHIR transformation complexity is consistently underestimated. Budget 30–40% more time for HL7-to-FHIR mapping than initial scoping suggests. Edge cases in legacy data are the rule, not the exception.
IAM least-privilege in healthcare requires understanding clinical workflows first. You cannot design the right permissions without knowing who needs what data at which point in a patient encounter.
KMS key policy design must involve the compliance and legal teams from day one, not as an afterthought after the architecture is built. Key custodianship decisions are organizational, not technical.
EventBridge schema registry pays for itself in documentation value alone. In organizations with multiple teams consuming events, the schema catalog becomes the de facto integration contract.
FinOps Transformation:
From Spend Chaos to Governed Cloud Economics
"We have no idea what our cloud is actually costing us by business unit. Engineering spins things up, finance gets a monthly bill with no context, and leadership has no visibility. We've been told we're wasting somewhere between 30 and 50 percent of our spend, but we can't prove it, and we can't fix what we can't see."
Context
A mid-market financial services firm operating across three business units had accumulated 240 AWS accounts with no organizational structure. Every account had been created independently, with no naming convention, no tagging policy, and no cost allocation model. Finance received a consolidated monthly bill and spent several days each month attempting to reconcile it with budget centers.
- 240 AWS accounts with no Organizations structure
- No tagging taxonomy; resources unattributable to business units
- Dev, test, and production environments co-mingled in same accounts
- No Reserved Instance or Savings Plan strategy; all workloads on on-demand pricing
- No cost anomaly detection; spend spikes discovered weeks after occurrence
Discovery
A four-week FinOps assessment surfaced the following: 60% of EC2 instances running at under 10% CPU utilization; 140 orphaned EBS volumes; S3 buckets with no lifecycle policies accumulating years of unread log data; and a substantial portion of compute eligible for Savings Plans that had never been purchased. The discovery also revealed a cultural problem: engineering teams had no feedback loop connecting their infrastructure decisions to cost outcomes.
Architectural Approach
The reference implementation establishes AWS Organizations as the governance foundation, restructuring accounts into Organizational Units aligned to security, infrastructure, business functions, and sandbox environments. Service Control Policies enforce tagging at resource creation; resources missing required tags cannot be provisioned. Cost and Usage Reports feed into Athena for SQL-queryable spend data, with QuickSight providing self-serve dashboards for finance and leadership. AWS Budgets triggers automated notifications and, for egregious overruns, remediation actions. Compute Optimizer and Savings Plans analysis replace the gut-feel approach to commitment purchasing.
Key Design Decisions
- OU-based structure over flat accounts: SCP inheritance creates cost boundaries without per-account policy management
- SCP tag enforcement at the Organizations level, eliminating tagging drift at source rather than remediating after the fact
- CUR + Athena over native Cost Explorer, enabling fully custom chargeback reports that finance teams can own and modify
- Savings Plans over Reserved Instances: lower operational complexity for a finance team with limited AWS fluency
- Anomaly detection before optimization; you cannot right-size what you cannot see
Trade-offs Accepted
- SCP tag enforcement initially blocked emergency deployments: resolved by implementing a break-glass process for P0 incidents before enabling enforcement
- Savings Plans less flexible than Reserved Instances: accepted for reduced operational overhead in a team without dedicated FinOps staff
- QuickSight licensing cost: justified by eliminating three days of manual Excel-based reporting per month from the finance team's workload
- Organizations restructuring required account migrations: a one-time cost accepted for long-term governance clarity
Engagement Highlights
Security
SCPs enforce security guardrails across all accounts; no cross-account resource sharing without explicit policy. Organization-wide CloudTrail provides a centralized, tamper-evident audit log. GuardDuty enabled organization-wide from the Security OU. Config rules enforce compliance baselines across all accounts.
Scalability
The Organizations structure supports unlimited account growth. New business units are onboarded as new OUs with inherited SCPs. The CUR + Athena architecture handles petabytes of cost data without provisioning infrastructure. QuickSight scales to all finance users without per-server licensing.
Cost Optimization
This framework is itself a cost optimization tool. The typical first engagement surfaces 30–40% in identifiable waste within 30 days. Savings Plans analysis identifies commitment opportunities. Compute Optimizer right-sizing eliminates over-provisioned instances. S3 lifecycle policies recover storage costs from unmanaged buckets.
This reference implementation provides a complete FinOps operating model for financial services organizations with multi-account, multi-business-unit AWS environments. The architecture enforces cost accountability at the account level, automates compliance with tagging policies through SCP enforcement, and gives finance teams native visibility into cloud spend without requiring engineering translation. The QuickSight executive dashboard replaces the monthly reconciliation exercise with a real-time view of cost by business unit, environment, and application. Cost anomaly detection shifts the organization from reactive to proactive spend management.
Lessons Learned
Tagging taxonomy must be agreed upon by finance, engineering, and leadership before implementation, not after. Every delayed decision creates orphaned resources that are politically difficult to clean up later.
SCPs are powerful but can block emergency operations. Design and test break-glass procedures simultaneously with SCP deployment, never as a follow-up task.
Savings Plans analysis should be run quarterly, not once. Workload composition changes with the business, and commitment recommendations drift out of alignment quickly.
FinOps is 20% tooling and 80% process change. Executive sponsorship is not optional; without it, cost accountability frameworks stall at the engineering layer and never reach the business unit level.
Multi-Tenant SaaS Architecture:
From Single-Tenant Chaos to Governed Isolation
"We have 85 enterprise customers. Each one has their own AWS account, their own CloudFormation stack, and their own set of configurations we manage manually. Onboarding a new customer takes two weeks and four engineers. Our growth projections say we'll have 300 customers in 18 months. The math doesn't work."
Context
A B2B SaaS provider had built its platform under a single-tenant model (one AWS account per enterprise customer) at a time when the customer count was manageable and compliance isolation requirements made this approach reasonable. As the business grew, the operational overhead became untenable: 85 separate environments to patch, monitor, and troubleshoot; no shared services; no self-serve onboarding.
- 85 customer accounts, each with identical infrastructure stacks
- New customer onboarding: 2–3 weeks, 3–4 engineers
- No shared logging, monitoring, or security tooling across accounts
- Zero tenant isolation testing, assumed but never validated
- No per-tenant usage metering for billing accuracy
Discovery
Architecture review identified four structural problems: identical infrastructure duplicated 85 times with no shared services layer; provisioning entirely manual with no API surface for automation; no formal tenant isolation model; isolation was implied by account separation but not enforced by policy; and no instrumentation for per-tenant resource consumption, making accurate usage-based billing impossible.
The discovery also clarified that not all customers required the same isolation level. Enterprise customers had contractual requirements for dedicated database instances; standard customers accepted pooled compute; self-serve customers had no isolation requirements beyond namespace separation.
Architectural Approach
The architecture implements a hybrid silo-bridge-pool tenancy model. Enterprise customers receive dedicated RDS instances for data isolation while sharing EKS compute through dedicated namespaces. Standard customers share pooled RDS instances protected by PostgreSQL row-level security policies, with resource quotas enforced at the Kubernetes namespace level. Self-serve customers share both compute and data within strictly metered namespaces. Amazon Cognito provides per-tenant user pools, with tenant identity propagated through JWT claims to the API Gateway authorizer layer. AWS CDK codifies the provisioning process into an idempotent API that onboards any tier in under 15 minutes.
Key Design Decisions
- Namespace-per-tenant over cluster-per-tenant: balances isolation with cost efficiency; Kubernetes network policies enforce hard boundaries
- Cognito user pools per tenant over shared pool: clean token-based tenant routing eliminates cross-tenant data exposure risk at the identity layer
- CDK for provisioning over Terraform: enables self-serve API surface; CDK constructs are composable and version-controlled like application code
- Row-level security for standard tier: strong isolation without the cost of dedicated instances; offloaded to a data access layer abstraction
- Per-tenant CloudWatch dimensions from day one; metering is not an afterthought; it enables usage-based billing and noisy-neighbor detection
Trade-offs Accepted
- Shared EKS cluster introduces noisy-neighbor risk: mitigated with resource quotas, limit ranges, and per-namespace metrics; accepted over cluster-per-tenant cost
- Row-level security adds query complexity: offloaded to a data access layer so application developers never write RLS-aware queries directly
- CDK more complex to maintain than static templates: investment in developer experience pays back through provisioning speed and reduced toil
- Per-tenant Cognito user pools increase cost at scale: justified by the clean isolation boundary and ability to set per-tenant MFA, password, and session policies
Engagement Highlights
Security
Cognito JWT tokens carry tenant claims enforced at the API Gateway authorizer. EKS network policies block all cross-namespace traffic. PostgreSQL RLS policies prevent cross-tenant row access at the database engine level. S3 bucket policies enforce tenant-prefix restrictions. WAF protects against application-layer attacks. Tenant data never commingled in logs or traces.
Scalability
Karpenter provisions EKS nodes intelligently based on pending pod requirements. Cluster Autoscaler handles horizontal scaling. RDS read replicas serve analytics without contending with transactional writes. The CDK provisioning API scales onboarding to any volume; no engineering involvement required per tenant. CloudWatch metrics scale per the service with no configuration changes.
Cost Optimization
Pooled compute reduces per-tenant infrastructure cost by an estimated 60–70% vs. single-tenant. Savings Plans on EKS node instance families recommended by Compute Optimizer. S3 Intelligent-Tiering for tenant data objects. RDS Reserved Instances for predictable base compute load. Per-tenant metering enables usage-based billing to align revenue with infrastructure costs.
This technical demonstration provides a complete blueprint for evolving a B2B SaaS platform from a single-tenant to a governed multi-tenant architecture. The hybrid silo-bridge-pool model enables the business to serve enterprise, mid-market, and self-serve customers from a single platform with appropriate isolation guarantees at each tier. The CDK provisioning API transforms customer onboarding from a weeks-long engineering project to a 15-minute automated process. Per-tenant metering unlocks usage-based billing accuracy and proactive noisy-neighbor detection. The architecture is designed to support growth from hundreds to thousands of tenants without structural change.
Lessons Learned
Define tenant isolation boundaries before writing a line of code. Retrofitting isolation into an existing platform is the most expensive re-architecture a SaaS company undertakes. The decision must precede the design.
The CDK provisioning API must be idempotent from day one. Partial provisioning failures happen. The system must be able to re-run provisioning for a tenant and arrive at the same correct state without duplicating resources or corrupting data.
Noisy neighbor is a real operational risk in shared environments. Instrument per-tenant resource consumption from day one; visibility into which tenants are consuming disproportionate compute is essential for both operations and fair billing.
Enterprise customers will ask for dedicated clusters. Design the pricing model to account for this before it becomes a sales conversation. The architecture should make dedicated-cluster provisioning a configuration option, not a custom engineering project.
Facing a challenge like these?
Every engagement begins with an honest conversation about your actual situation, not a sales pitch. Bring your questions.