Durable Workflow Orchestration
Temporal vs AWS Step Functions: how do security/compliance and data exposure compare if workers run in our VPC?
8 min read
Quick Answer: When your Workers run in your own VPC, Temporal exposes far less of your application surface area than AWS Step Functions. Temporal Cloud never runs your code, never needs plaintext data, and only sees encrypted event histories, while Step Functions executes logic and passes payloads inside your AWS account.
Frequently Asked Questions
How does security and data exposure differ between Temporal and AWS Step Functions if my Workers run in my VPC?
Short Answer: With Temporal, your code and sensitive data stay in your infrastructure and only encrypted event metadata flows to the Temporal Service; with AWS Step Functions, your orchestration runs inside your AWS account and typically sees the full payload for each step.
Expanded Explanation:
Temporal’s model is deliberately split: Workflows and Activities are just code in your services, running inside your own VPC or environment. The Temporal Service (Temporal Cloud or self-hosted) coordinates execution but never runs your code. All calls from your Workers to the Service are outbound-only and can be encrypted end-to-end with your own keys. The Service stores deterministic event histories—not raw business objects—so it can drive replay and recovery without requiring access to your plaintext domain data.
AWS Step Functions, by design, is an in-account orchestration engine. It runs your state machine definitions, evaluates conditions, and passes input/output payloads between steps. That usually means full request bodies, tokens, and intermediate results are visible to the Step Functions service and logged in execution history unless you explicitly filter or encrypt them. You get tight integration with AWS IAM and private networking, but the service is still directly handling your data.
Key Takeaways:
- Temporal coordinates execution but never runs your code and does not need plaintext business data.
- Step Functions executes state machines in your AWS account and typically handles complete payloads between steps.
How does Temporal’s security model work when Workers are in my VPC?
Short Answer: Temporal keeps all Workflow and Activity code running in your environment and uses secure, unidirectional connections to the Temporal Service, which stores only encrypted event histories.
Expanded Explanation:
When you use Temporal, you deploy Workers—your Workflows and Activities—as part of your existing services, on your own infrastructure (AWS VPC, on‑prem, Kubernetes, etc.). Those Workers initiate outbound connections to the Temporal Service. There’s no need to open inbound firewall ports; the Service never reaches into your VPC. All data leaving your environment can be encrypted with your own library and keys before it ever hits the wire. Temporal Cloud never needs to see your data in clear text.
The Temporal Service persists execution histories: events like “Activity A scheduled,” “timer fired,” “signal received.” On crash or redeploy, a Worker replays that history to reconstruct state and continue execution. This is how we get “code that always finishes” without running your code on our side. Either way, we never see your code.
Steps:
- Deploy Workers (Workflow/Activity code) into your VPC or cluster, alongside your other services.
- Configure Workers to connect outbound to Temporal (Cloud or self-hosted) over TLS, with your auth and encryption strategy.
- Let Temporal persist execution histories while your Workers hold and process any sensitive business data locally.
How does AWS Step Functions compare in terms of security, compliance, and data exposure?
Short Answer: Step Functions runs orchestrations and processes payloads inside your AWS account, tightly integrated with IAM and VPCs, but the service typically sees full step inputs/outputs and stores them in execution history.
Expanded Explanation:
Step Functions is a managed orchestration service that lives entirely within AWS. You define a state machine in Amazon States Language; Step Functions executes it, calling Lambda functions, ECS tasks, or other AWS services. The service typically receives and stores the JSON payloads you send between states. Data appears in execution history and CloudWatch logs unless you explicitly mask or encrypt it.
From a compliance standpoint, this can be an advantage if your entire workload is already constrained to a single AWS region and governed by AWS’ certifications (HIPAA-eligible services, SOC, PCI scope, etc.). On the other hand, it also means your sensitive payloads are directly handled by another AWS service layer. You have to design payload shapes, redaction, and encryption so that what lands in Step Functions’ history and logs conforms to your compliance posture.
Comparison Snapshot:
-
Option A: Temporal (Workers in your VPC)
- Code runs in your environment.
- Temporal Service stores event histories; you can encrypt data before it leaves your VPC.
- Unidirectional, outbound-only connections; no firewall holes.
-
Option B: AWS Step Functions
- Orchestration runs as an AWS managed service in your account.
- Typically handles full JSON payloads for each step; stored in execution history.
- Tight IAM integration and regional compliance footprints.
-
Best for:
- Temporal: teams that want to keep business logic and sensitive data in their own environment (or multi-cloud), minimize data exposure, and still get durable execution.
- Step Functions: teams all‑in on AWS who are comfortable with AWS seeing step payloads and want native integrations over maximum data minimization.
How do compliance responsibilities and boundaries differ between Temporal and Step Functions?
Short Answer: Temporal lets you keep most compliance scope in your own environment because code and data reside in your VPC; Step Functions places more of your orchestration—and frequently your payloads—inside AWS’ managed boundary.
Expanded Explanation:
With Temporal, the trust boundary is crisp: you own the Workers, your data, and your keys; Temporal provides durable coordination. Because all communication is outbound and can be encrypted with your own keys, you can often treat Temporal Cloud more like a control plane than a data plane. For many regulated workloads, that means most of the heavy compliance lifting (PII, PCI, PHI handling) stays within your own audited infrastructure. Temporal’s role is to store and sequence events, not to run or inspect your business logic.
With Step Functions, orchestration logic and payloads live within AWS. This aligns well if your auditors already accept AWS as your primary regulated environment, but it changes your threat model: any data you pass into the state machine may be observable to AWS services and support tooling. You’ll rely on AWS’ shared-responsibility model, IAM configuration, and log governance to keep that data in‑scope and protected.
What You Need:
- For Temporal:
- A deployment target for Workers in your own VPC or infrastructure (Kubernetes, ECS, VMs).
- A security model (TLS, encryption, identity) for outbound connections to Temporal Service and any sensitive fields you choose to encrypt at the app level.
- For Step Functions:
- A clear policy for what data can enter state machines and how it’s redacted or encrypted.
- Robust IAM, VPC, and logging controls to keep Step Functions histories and logs compliant.
Strategically, when should I favor Temporal over Step Functions for security and data exposure?
Short Answer: Favor Temporal when you want durable orchestration without handing a cloud provider your business logic and data; stick with Step Functions when you’re fully AWS-centric and comfortable putting payloads into AWS-managed state machines.
Expanded Explanation:
Without Temporal, the usual options are: accept that AWS orchestration services (Step Functions, EventBridge, etc.) will see your payloads and some of your control logic, or build your own brittle state machines and retry loops hidden inside microservices. Temporal offers a different default: keep your code close, but offload reliability and state persistence to a dedicated Durable Execution engine.
If your priority is minimizing external data exposure—especially for regulated data like cardholder info, medical records, or highly proprietary models—Temporal’s separation of concerns is a strategic advantage. Workflows and Activities live in your repos, your containers, your VPC. Temporal Cloud or self-hosted Temporal only coordinates, persists event histories, and enables replay. Either way, we never see your code.
Step Functions remains a strong choice when your team is deeply invested in AWS primitives, you want tight integration with other AWS services, and your compliance framework is already oriented around AWS as a single trusted infrastructure provider. In that world, the incremental data exposure from Step Functions may be acceptable or even trivial.
Why It Matters:
- Data exposure and code placement are architectural decisions, not just configuration choices; they shape what your auditors will care about and how painful migrations become.
- Temporal lets you “outsource reliability” without exporting your business logic or sensitive data to a vendor, giving you durable execution with a smaller expansion of your compliance surface area.
Quick Recap
When your Workers run in your VPC, Temporal and AWS Step Functions make fundamentally different security and data exposure trade‑offs. Temporal keeps Workflows and Activities as code in your environment, uses outbound-only encrypted connections, and persists event histories instead of raw business data—so your compliance scope largely stays where it is today. Step Functions runs state machines inside AWS, typically seeing full payloads between steps and storing them in execution history, which can be ideal if you’re all‑in on AWS but expands the managed-service layer that handles your data.