Durable Workflow Orchestration
Temporal vs AWS Step Functions: how do security/compliance and data exposure compare if workers run in our VPC?
9 min read
Failures are inevitable. The real question is: when something breaks, who sees your data and who can still get your workflow safely to completion—especially when your workers run inside your own VPC?
Quick Answer: If your workers run in your VPC, Temporal is designed so that your sensitive data and code never leave your environment; the Temporal Service (including Temporal Cloud) only sees encrypted payloads and event metadata. With AWS Step Functions, the orchestrator itself runs inside your AWS account and often sees your raw inputs, outputs, and step parameters unless you explicitly encrypt or tokenize them. Both can be compliant, but the exposure model and blast radius are very different.
Frequently Asked Questions
How does data exposure differ between Temporal and AWS Step Functions if my workers run in my VPC?
Short Answer: With Temporal, your Workflow and Activity code plus clear‑text data stay in your VPC; the Temporal Service only sees encrypted payloads and execution history. With AWS Step Functions, the managed service runs in your AWS account and typically has visibility into step inputs/outputs unless you design around that.
Expanded Explanation:
Temporal was built with the assumption that you don’t want to ship your code or sensitive business data into somebody else’s compute. You run Workers (your Workflow and Activity code) in your own environment—your VPC, your Kubernetes cluster, your bare metal. They connect out to the Temporal Service over a unidirectional, encrypted channel. You encrypt payloads in your app with your keys and your crypto libraries. The Service stores an event history that is enough to replay and recover state, but it never needs to see clear‑text PII, payment data, or secrets. Either way, we never see your code.
AWS Step Functions is different in one critical way: the orchestrator is an AWS‑managed service that you call with JSON inputs and that orchestrates other AWS services using IAM roles in your account. It usually has full visibility into state machine definitions, parameters, and the raw JSON documents you pass between steps. You can of course encrypt data at rest, use KMS, and minimize what you send—but the model assumes the control plane can see your data, and your workflows and state are tightly bound to AWS.
Key Takeaways:
- Temporal keeps your code and clear‑text data in your VPC; the Service only stores encrypted payloads and metadata needed for durable execution.
- Step Functions’ control plane typically sees state machine definitions and JSON inputs/outputs, increasing the surface area of data exposure unless you aggressively tokenize or encrypt.
What’s the security architecture when Temporal Workers run in my VPC?
Short Answer: Workers stay in your VPC, connect out to the Temporal Service over TLS, and push already‑encrypted payloads. You never open inbound firewall ports, and the Service never needs access to clear‑text data.
Expanded Explanation:
Temporal’s security model is intentionally asymmetric. Your Workers—where your business logic runs—live in your environment. They poll Temporal task queues over a secure, outbound connection. All connections from your app to the Temporal Service are unidirectional so you never need to open up the firewall.
Before data leaves your network, you can encrypt it with your own libraries and keys. The Temporal Service stores the encrypted blobs plus event metadata in its durable history. That history drives everything: crash recovery, replay, visibility in the Web UI. Because the Service never needs to inspect payload contents, it doesn’t require access to secrets or customer data in clear text. Temporal Cloud follows the same pattern: open-source SDKs + Workers in your infra, Service in Temporal’s cloud, unidirectional encrypted connections, no code or clear‑text data crossing the boundary.
By contrast, Step Functions runs fully inside AWS. You grant it IAM roles to call Lambda, SQS, DynamoDB, and other services on your behalf. You’re still inside your AWS account boundary, but your JSON inputs/outputs flow through a managed control plane that is designed to inspect and route them. There’s no concept of running the Step Functions “engine” inside your own VPC—only the tasks.
Steps:
- Deploy Workflow and Activity Workers in your VPC or cluster (Go, Java, TypeScript, Python, .NET).
- Configure secure, outbound connections from Workers to the Temporal Service (self-hosted or Temporal Cloud).
- Encrypt payloads in your code before sending them; let Temporal store only encrypted data plus event history.
How do Temporal and AWS Step Functions compare on security boundaries and blast radius?
Short Answer: Temporal isolates execution so that clear‑text data and code are confined to your environment; the Service operates on encrypted histories. Step Functions lives inside your AWS account and typically processes raw inputs/outputs, tying your security posture directly to AWS account and IAM configurations.
Expanded Explanation:
Think about what happens when something goes wrong—an IAM misconfiguration, an over‑permissive role, a compromised credential. With Step Functions, the orchestrator is part of your AWS control plane. If an attacker can act as Step Functions with sufficient permissions, they can potentially traverse many services, see raw state machine inputs, and pivot across your environment. Your blast radius is coupled to your AWS account and IAM hygiene.
With Temporal, the boundary is different. The only thing the Service can do is schedule Tasks, persist Workflow histories, and hand Tasks to Workers. It cannot directly call your databases, your queues, or your microservices. All those integrations happen in Worker code running in your VPC. The Service only sees encrypted payloads and metadata like Workflow IDs, task queue names, and Activity types. Even in a worst‑case scenario where someone gains read access to Temporal’s storage, they get encrypted blobs, not card numbers or PHI.
Comparison Snapshot:
- Option A: Temporal with Workers in your VPC
- Code and clear‑text data remain in your infra.
- Temporal Service stores encrypted event histories and orchestrates via task queues.
- No inbound firewall rules; unidirectional outbound connections only.
- Option B: AWS Step Functions
- Orchestrator runs as an AWS managed service inside your AWS account.
- Typically sees raw JSON inputs/outputs and state machine definitions.
- Relies heavily on IAM scopes and account isolation for blast-radius control.
- Best for: Teams that want strict separation between orchestration control plane and data plane, minimal data exposure to vendors, and the option to self‑host or use Temporal Cloud with the same security model.
How do compliance and regulatory requirements play out between Temporal and Step Functions?
Short Answer: Both can be used in compliant environments, but Temporal’s design makes it easier to prove that code and clear‑text data never leave your controlled environment, while Step Functions ties your compliance story to AWS account boundaries and managed‑service certifications.
Expanded Explanation:
If you operate in regulated spaces—payments, healthcare, fintech, insurance—you care about where code runs, where data sits, and who can see what. Temporal gives you two levers:
- You can self‑host the Temporal Service entirely inside your own environment, under your own compliance umbrella.
- Or you can use Temporal Cloud with the same architecture: Workers and clear‑text data stay in your VPC; Temporal Cloud persists only encrypted payloads and histories.
In both scenarios, your auditors will ask: does any vendor ever see cardholder data, PHI, or secrets? With Temporal, the answer is: no, unless you explicitly choose to send it in clear text. The platform is secure by design: “Either way, we never see your code.” All data transfer is encrypted before it leaves your environment, and the Service never needs your data in clear text.
With Step Functions, you leverage AWS’s compliance portfolio (PCI, HIPAA-eligible services, SOC, etc.). That’s powerful—but the orchestrator is fundamentally part of AWS’s managed infrastructure. When auditors ask who can see which data, your answer is rooted in AWS shared responsibility, IAM configurations, KMS policies, and the assumption that Step Functions can inspect the inputs you give it. It’s compliant, but it’s a different trust model: you’re betting on AWS as your full control plane, not just your infrastructure provider.
What You Need:
- For Temporal:
- A place to run Workers and (optionally) the Temporal Service in your own compliant environment.
- Encryption and key management aligned with your regulatory requirements.
- For Step Functions:
- AWS accounts and IAM practices that meet your regulatory standards.
- Proper KMS usage, logging, and data minimization in state machine inputs/outputs.
Strategically, when should I prefer Temporal over AWS Step Functions for security, compliance, and data exposure?
Short Answer: Prefer Temporal when you want durable execution without expanding your data exposure to a cloud orchestration control plane, need multi‑cloud or hybrid options, or must demonstrate that third parties never see your code or clear‑text data.
Expanded Explanation:
Step Functions is a good fit if you are all‑in on AWS, happy with AWS as your primary control plane, and your security model already assumes that managed services see your JSON payloads. It shines for wiring together AWS services quickly, especially for shorter‑lived workflows where vendor lock‑in and cross‑cloud control aren’t concerns.
Temporal is built for teams that see reliability as an application primitive and data sovereignty as non‑negotiable. You stop building brittle state machines and ad hoc retry logic inside microservices. Instead, you write Workflows and Activities as normal code, run them in your VPC, and let the Temporal Service coordinate durable execution via event histories and replay. When workers crash, you replay from history and pick up where you left off—without the Service needing any clear‑text business data.
Strategically, this shifts your posture:
- Your code stays yours. Workers are just your binaries; the Service never runs your code.
- Your data stays in your trust boundary. Encrypted payloads leave your VPC; clear‑text doesn’t.
- Your architecture stays portable. You can self‑host or use Temporal Cloud in multiple regions without rewriting workflows around a specific cloud’s orchestration engine.
Why It Matters:
- Reduced data exposure: A thinner, encrypted control plane means fewer systems and vendors with access to sensitive payloads, lowering risk and simplifying compliance narratives.
- Long‑term flexibility: Temporal’s model lets you change where the Service runs (self‑hosted or cloud, single or multi‑region) without changing where your code and data live, avoiding deep lock‑in to a single cloud control plane.
Quick Recap
When your workers run in your VPC, Temporal and AWS Step Functions offer two very different security and data‑exposure stories. Temporal keeps your Workflow and Activity code—and your clear‑text data—entirely inside your environment. The Temporal Service (or Temporal Cloud) only sees encrypted payloads and execution metadata, coordinating durable execution without ever running your code or reading your secrets. AWS Step Functions, by design, runs as a managed service inside your AWS account and typically sees your raw JSON inputs, outputs, and state machine definitions, tying your blast radius and compliance posture directly to AWS’s control plane and your IAM configuration. Both can be compliant, but Temporal gives you a smaller data exposure surface and more control over where code and data live.