> MicroVMs support up to 8 hours of total runtime

Does this mean you effectively can't use them as long-lived developer environments? It sounds like even if you suspend them, this is the hard limit on the total time it can run.

▲

topspin 3 hours ago | parent | next [-]

It just a time limit of the life of a single MicroVM.

Using this for a long lived "developer environment" would be extraordinarily expensive anyhow. Scaling the vCPU + RAM cost of these to the same shape compute optimized Graviton On-Demand EC2 instance (16 vCPU x 32 GB RAM) shows about 4x the cost.

So don't do that. Just use an EC2 instance.

	▲	tomComb 2 hours ago \| parent [-]
		But these have near instant suspended/resume, and they even have vertical scaling of the ram, which is a great feature that’s not very common.

▲

mmastrac 3 hours ago | parent | prev | next [-]

They are long-lived if you're a mayfly.

But I think the point is that they should be cheap to set up, and because of the short life, never really contain anything except the potential to compute when needed, not important data.

▲

alFReD-NSH an hour ago | parent | prev | next [-]

In theory, you could set up a process to move data/filesystem between sessions into and out of s3.

▲

amw-zero 3 hours ago | parent | prev | next [-]

You can use them for dev environments.

You just have to finish development in 8 hours.

▲

lab14 3 hours ago | parent | prev | next [-]

I'm assuming you can launch them again after 8 hours.

▲

8note 3 hours ago | parent | prev [-]

lambdas are ephemeral on compute, but couldn't you connect up EFS for your long lived data?

then when you launch the next one, its like you are still there?

	▲	mdeeks 2 hours ago \| parent [-]
		EFS is extremely slow for many workloads. We tried it for builds and various other common use cases for coding agents and the performance just isn't there. I'm guessing lots of small random reads/writes just isn't going to ever work well.