No-Code SaaS Automation Platform  ·  View 07 of 21  ·  Structure

Container View

The deployable units and their AWS services, with credential custody in its own account.

Editable source SVG draw.io All views
AWS eu-west-1 — platform account Author and control plane Author API API Gateway Editor and repair UI Fargate Definition registry Aurora Connector catalogue DynamoDB + S3 Ingest plane Push endpoints ALB + Fargate Poll workers Fargate Cursors and subs DynamoDB Trigger event log MSK Execution plane Run admission SQS queue classes Step runners Fargate Step ledger DynamoDB Egress and connector plane Quota governor Fargate Connector sandbox Lambda NAT, static range Credential account — separate blast radius Credential custody Fargate Workspace keys KMS Third-party SaaS APIs not ours publish commit admit lease attempt effect run token allowlisted Container View — Platform Internals Interface / broker Application we own Data store Queue / topic Security / platform External / third party synchronous Custody sits in its own account: a compromise of the execution plane must not be a compromise of the customers' other SaaS products. v 1.0 · owner Integration Platform Architecture · date 2026-10

Decisions

  • Credential custody lives in a separate AWS account, not merely a separate service. The threat being designed against is a compromise of our own execution plane becoming a compromise of the customers' other SaaS products.
  • The connector sandbox is Lambda rather than a container in the runner: partner-submitted code must not share a process, a filesystem or a network namespace with the run.
  • MSK for the trigger event log and DynamoDB for the step ledger — a partitioned replayable log for 'what happened', a high-write key-value store for 'where is this run'. Those are different access patterns and resisting one store for both is the point.

Assumptions

  • Fargate rather than EC2 for every tier, accepting a per-task cost premium to keep the idle-automation cost near zero (≤ $0.004/automation/month).
  • Aurora for the definition registry because publication is strongly consistent and low-volume; DynamoDB for the catalogue because reads are hot and shapes vary.

Risks

  • The quota governor is on the path of every outbound call and is therefore the platform's hottest single dependency — Core Architecture Question 2 is about exactly this.
  • A cross-account hop for every token exchange adds latency to each step; mitigated by caching the short-lived token for the run's duration, which widens the revocation window.
◀  Layered Architecture All views Interface Catalogue  ▶
Solution Architecture v1.0 · Amazon Web Services · Integration Platform Architecture · 2026-10 · 21 views07-container-view