Deploying Temporal on AWS Ecs with Terraform

Posted2 months agoActiveabout 1 month ago

norapap

3 points

2 comments

papnori.github.ioTechstory

calmpositive

Debate

20/100

TemporalAWS EcsTerraformCloud Computing

Key topics

Temporal

AWS Ecs

Terraform

Cloud Computing

The article discusses deploying Temporal on AWS ECS using Terraform, with commenters raising questions about scaling, workflow management, and the benefits of using Temporal over AWS services.

Snapshot generated from the HN discussion

Discussion Activity

Moderate engagement

First comment

13m

Peak period

Days 13-14

Avg / period

4.3

Key moments

01Story posted
Nov 5, 2025 at 1:00 AM EST
2 months ago
Step 01
02First comment
Nov 5, 2025 at 1:13 AM EST
13m after posting
Step 02
03Peak activity
9 comments in Days 13-14
Hottest window of the conversation
Step 03
04Latest activity
Nov 26, 2025 at 2:58 PM EST
about 1 month ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (2 comments)

Showing 13 comments

DoofWarrior

2 months ago

1 reply

Why go with Fargate instead of EC2?

norapapAuthor

2 months ago

1 reply

We went with Fargate because it keeps things lean — no servers to manage, no patching, no scaling headaches. It’s perfect for our bursty workloads, since we only pay when containers actually run . Plus autoscaling just works .

In the github you can find comments to easily switch to EC2 if your workload needs it

leetrout

about 2 months ago

Just as an aside for the fargate convo... we switched from fargate to EC2 auto scaling group so we could run a custom AMI that has our container images (which are larger than I like) pre-baked and we went from a ~3 minute startup in fargate to ~30 seconds with the ASG when it's not triggering a scaling action.

We're using prefect not Temporal and each prefect flow launches in a discrete ECS task so the waiting added up.

jarboot

about 2 months ago

1 reply

> Autoscaling is configured via CloudWatch alarms on CPU usage: > Scale-out policy adds workers when CPU > 30%. > Scale-in policy removes idle workers when CPU < 20%.

Does this handle the case where there are longer-running activities that have low CPU usage? Couldn't these be canceled during scalein?

Temporal would retry them, but it would make some workflow runs take longer, which could be annoying for some user-interactive workflows.

Otherwise I've seen needing to hit the metrics endpoint to query things like `worker_task_slots_available` to scale up, or query pending activities, pending workflows, etc to scale down per worker.

norapapAuthor

about 1 month ago

They can be cancelled if CPU drops below the scale-in threshold. In my case the activities were CPU-heavy, batch-style, and not client-facing — so preferred occasional retries and slightly longer runtimes over blowing up the AWS bill. For that workload, CPU-based autoscaling was perfectly fine.

I originally ran this setup on Temporal Cloud, and pulling detailed worker/queue metrics directly from Cloud can be tricky... you need to expose custom worker metrics yourself, then pipe them into CloudWatch. If you host Temporal yourself, it is easier:)

llmslave

about 2 months ago

1 reply

Whats funny is in some sense, temporal replaces alot of the AWS stack. You dont really need queues, step functions, lambdas, and the rest. I personally think its a better compute model than the wildly complicated AWS infra. Deploying temporal on compute primitives is simply better, and allows for you to be cloud agnostic.

causal

about 2 months ago

2 replies

I sometimes suspect AWS deliberately looks for ways to extract low-overhead tasks into dedicated services for the simple reason that many people will pay for the service without thinking about whether they really need it.

llmslave

about 2 months ago

1 reply

Its very easy to add AWS services, but after building them into a stack over a few years, its basically impossible to remove them

bithavoc

about 2 months ago

yes, one word: IAM

swyx

about 2 months ago

same guys worked on temporal as aws step functions. they just learned over time.

jen20

about 2 months ago

2 replies

This article is really about hosting Temporal _workers_ in ECS - which is the "easy" part - not running the Temporal service itself. That would be a valuable follow-up!

whalesalad

about 2 months ago

99.9% sure the entire article was written by Claude or ChatGPT - so you can probably direct that question at the source.

norapapAuthor

about 1 month ago

I found a lot of guides and articles on how to host Temporal - they have it in the official docs also:)

View full discussion on Hacker News

ID: 45819731Type: storyLast synced: 11/17/2025, 7:53:03 AM

Want the full context?