How Diaflow Achieved Active-Active Architecture and SOC 2 Compliance in 28 Days

Every enterprise security questionnaire asks two things early: show us your SOC 2 report, and tell us how you fail over between regions. For a fast-growing SaaS platform, those two answers are the gate between the current customer base and the next tier of contracts.

Diaflow is an AI-native automation platform. To close enterprise deals it had to deploy multi-region infrastructure and meet strict compliance requirements (SOC 2, HIPAA, GDPR) at the same time. With CloudThinker, Diaflow compressed a standard 6-month roadmap into a 4-week sprint, reaching 99.9% uptime and reducing operational toil by 80%.

---

When growth becomes the bottleneck

Diaflow processes over 1 million monthly workflows for thousands of global customers. The systems that served that traffic were not the systems the next tier of enterprise contracts demanded. Three requirements landed at once:

1. Global latency. Active-active deployment across multiple AWS regions, now.
2. Regulatory hardening. SOC 2, HIPAA and GDPR readiness to unblock the enterprise pipeline.
3. Velocity. None of that could slow down feature shipping.

Why the traditional route takes six months or more

The usual answer is to hire specialized cloud architects and security engineers. That carried a 6-to-12-month lead time, which doesn't work in a market where speed is the main differentiator. The lead time isn't only hiring. The work itself is structured to be slow:

Architecture and compliance run in sequence. A team designs the multi-region topology, builds it, and then a compliance effort audits what was built. Every finding (encryption at rest, IAM least privilege, logging) means reopening infrastructure that's already live.

State is the hard part, and it comes late. Moving stateless services between regions is routine. Replicating databases with acceptable lag and clean failover is where projects stall, and it's usually discovered after the easy wins are done.

Compliance evidence is a spreadsheet exercise. Controls get documented once for the audit and drift the week after. The next audit starts from scratch.

Day 2 isn't planned. A multi-region footprint doubles the surface to monitor and the bill to watch. Without automation, the ops load lands on the same developers who are supposed to be shipping features.

Four workstreams, one architecture

Diaflow partnered with CloudThinker for a unified, AI-driven operations approach instead of adding contractors to the team. The work ran as four workstreams against the same architecture:

01Migration

Active-active

Cloud-native, multi-region topology with zero downtime during the move.

02Optimization

30-40% lower cost

Right-sizing, resource scheduling and Savings Plan recommendations.

03Security

Continuous

Vulnerability scanning and misconfiguration detection with automated remediation.

04Compliance

SOC 2, HIPAA, GDPR

Monitoring, evidence and policy enforcement running in the background.

1. Cloud migration and modernization. Instead of "lift and shift", CloudThinker architected a migration to a cloud-native, active-active topology. The transition had zero downtime, with configurations optimized from day 0.
2. Cloud optimization. Multi-region deployment tends to spiral cost. Right-sizing and resource scheduling drove a 30-40% cost reduction compared to manual provisioning.
3. Security assessment. Security ran as a continuous process, not an audit step: vulnerability scanning and misconfiguration detection across the infrastructure, with automated remediation.
4. Compliance. Monitoring and reporting for SOC 2, GDPR and HIPAA were automated. Real-time audit trails and programmatic policy enforcement turned compliance into a background process instead of a manual burden.

The 4-week sprint

01Weeks 1 to 2

Design and map

Topology designed, compliance gaps fixed in Terraform before anything was provisioned.

02Week 3

Distribute state

Multi-region databases and EKS tuned for failover and zero downtime.

03Week 4

Operate

Observability, routine remediation and cost governance handed over.

The phases overlapped on purpose, so the four workstreams could inform each other instead of producing rework.

Phase 1: architecture and compliance mapping (weeks 1-2)

The work started secure by design.

• Topology design (migration). A global VPC peering strategy for low-latency inter-region communication.
• Gap analysis (compliance). The proposed architecture was scanned while it was still code. Gaps in encryption at rest and IAM least-privilege access were found and fixed in the Terraform definitions before a single resource was provisioned.

That second point is where most of the six months disappears in the traditional route. A finding in a Terraform plan is a code review comment, for example:

resource "aws_rds_cluster" "workflows" {
  cluster_identifier = "workflows-primary"
  engine             = "aurora-postgresql"
  storage_encrypted  = true
  kms_key_id         = aws_kms_key.data.arn
  # ...
}

The same finding in a running account is a migration.

Phase 2: the stateful challenge (week 3)

Moving stateless microservices is routine. Distributing state is the real engineering problem.

• Database orchestration. Multi-region clusters with automated failover logic, with replication lag tuned for data consistency across regions.
• Kubernetes (EKS) orchestration. Node scaling policies and rolling update strategies on EKS to meet the zero-downtime mandate.

Phase 3: observability and handover (week 4)

The last phase covered day 2: keeping the system stable and cost-efficient after launch.

• Self-healing (security). An observability mesh categorizes incidents by severity. Routine issues, like hung pods or resource exhaustion, trigger automated remediation workflows.
• Cost governance (optimization). Savings Plan recommendations and resource scheduling keep the new global footprint within budget.

---

Root cause in minutes, not days

The biggest day-to-day change was Mean Time to Resolution (MTTR), which moved from days to minutes.

In a distributed architecture, debugging is hard. A latency spike could start in the application layer (Kubernetes), the data layer (Postgres) or the network layer (AWS). CloudThinker correlates telemetry across all of them at once: AWS infrastructure, Kubernetes, the database and application logs.

01Signals

Diaflow stack

• Grafana and PrometheusMetrics and alert rules
• DatadogMonitors and logs
• Kubernetes (EKS)Pods, nodes, rollouts
• AWSCloudFront, S3, databases, CloudTrail
• GitHub and GitLabRecent changes and pipelines

Alerts arrive by webhook

02Investigation

CloudThinker

• CorrelateAll layers at once, one timeline
• Test hypothesesEach reading checked against data
• Root causeWith the evidence cited

Read-only by default

03Outcome

In the thread

• Key findingsWhat fired and what it means
• Recommended actionsFix plus prevention, with snippets
• ResolutionApplied, verified, recorded

Minutes, not days

A real incident: the CloudFront and S3 Content-Type disconnect

01Report

Broken images

PNG assets served as text/xml instead of image/png.

02Readings

Three suspects

Wrong S3 metadata, a header rewrite at the edge, or a stale cache.

03Evidence

S3 vs edge

S3 says image/png. The edge serves an old cached copy.

04Fix

Invalidate

Cache invalidation created and confirmed complete.

05Prevent

Upload rule

Content-Type set at upload, with code snippets.

The report. Users saw broken image assets. PNG files failed to render because they arrived with Content-Type: text/xml instead of image/png.

The old way (6-24 hours). Engineers inspect S3 metadata by hand, review CloudFront configs, check cache policies, test URLs and trace the upload pipeline, while users keep seeing broken pages.

The readings. A wrong header at the browser has three plausible sources, and each predicts something different:

• The object in S3 has the wrong metadata. Then S3 itself returns text/xml.
• Something at the edge rewrites the header. Then every object behind that cache behavior gets the wrong header, PNG or not.
• CloudFront is serving a stale cached copy. Then the edge response is old (a high Age, a cache hit) and differs from what S3 returns now.

The checks. Compare what the edge serves with what the origin holds. The edge response (values below are illustrative):

curl -sI https://assets.example.com/img/workflow-card.png
# content-type: text/xml
# x-cache: Hit from cloudfront
# age: 172800

The object in S3:

aws s3api head-object --bucket example-assets --key img/workflow-card.png
# "ContentType": "image/png"

The finding. S3 had the correct metadata (image/png), but CloudFront was serving cached responses with the wrong header. Root cause: files had been uploaded without a Content-Type, later fixed in S3, but the cache stayed stale. CloudThinker found the CloudFront distribution and tied the Content-Type errors to those stale cached responses.

The fix. Create a cache invalidation and confirm it completed:

aws cloudfront create-invalidation \
  --distribution-id E2EXAMPLE123 \
  --paths "/img/*"

aws cloudfront get-invalidation \
  --distribution-id E2EXAMPLE123 \
  --id I2J0I21PCUYOIK
# "Status": "Completed"

The prevention. Recommendations with code snippets so it can't recur, starting with setting the Content-Type at upload time instead of fixing it afterwards:

aws s3 cp workflow-card.png s3://example-assets/img/workflow-card.png \
  --content-type image/png

The result. A multi-hour outage resolved in 15 minutes, with both the immediate fix and the long-term prevention delivered, and no manual troubleshooting.

The deeper difference is the order of the work. An engineer working alone has to check one layer, then the next, and only learns which layer mattered at the end. CloudThinker checks the layers side by side, so the comparison between S3 and the edge, which is the whole answer here, happens first instead of last.

---

The quantitative impact

Gated by design

Automated remediation only works if the team knows exactly what runs on its own. CloudThinker acts within Auto Mode, so the team decides what runs on its own, like restarting a hung pod, and what waits for approval, like a scaling change. Every action lands in the audit trail. For a SOC 2 program that's useful twice: once for operations, and again as evidence.

What changed for the team

The immediate value for Diaflow was speed. The longer-term value is operational leverage.

In a traditional model, the DevOps team grows linearly with the platform. By handing the day-to-day load of infrastructure management to CloudThinker, Diaflow decoupled headcount from scale. Conversations moved from infrastructure constraints ("Can the database handle this load?") to product opportunities ("How fast can we ingest this new dataset?").

Getting started

If you're facing the same mix of multi-region and compliance work, start with a read-only connection and ask from chat:

"Review our Terraform for the production account against SOC 2 controls. List encryption, IAM and logging gaps with the exact resource and the change that fixes it. Propose only, change nothing."

"Users report images rendering broken from our CDN. Compare what CloudFront serves with what S3 holds for the affected objects and tell me which layer is wrong."

"Show me which resources in our second region are oversized compared with their last 30 days of use."

Conclusion

Diaflow needed active-active infrastructure and SOC 2 readiness at the same time, without slowing the product down. Running migration, optimization, security and compliance in parallel against one architecture got it there in four weeks instead of six months. The team now builds product while the platform keeps itself compliant, efficient and fast to debug.

Want to plan the same sprint for your platform? Talk to our team.