| ▲ | 0xbadcafebee 2 hours ago | ||||||||||||||||||||||
That's literally why they made Fargate. It's managed firecracker VMs with containers. They invented firecracker for this purpose. This new product is competing with Fargate, but they don't mention Fargate at all in the announcement.
So you're already using containers with this new thing, same as Fargate! And not only that, it's more limited in runtime than Fargate! The only thing different with this service is stateful file storage, which is actually a problem you later have to engineer around, which is why containers are stateless.This smells like a competing team building something to capitalize on AI hype, but the product isn't differentiated enough for this to make sense long term. If this was a service called managed AI agents, and you added features specific to AI agents, that has value. But "here's Fargate with a different name" isn't gonna last. | |||||||||||||||||||||||
| ▲ | simonreiff 29 minutes ago | parent | next [-] | ||||||||||||||||||||||
I don't think Fargate fits for the use case they are describing. If you're running your own (trusted) code, then of course there's no reason to worry about containment threats. But the threat here is that you have to execute arbitrary, untrusted code that is presumptively malicious. It's a very different scenario and requires considerable measures to safeguard properly. You can't have a Fargate Task that runs multiple containers, one for each user, for instance, or even run multiple Fargate Task instances, one for each user, because you're still having them all share a virtual EC2 host (well technically a pool of EC2 servers but it's one hypervisor and shared virtual kernel, essentially) that would be compromised if any one container escapes. If you need true hypervisor-level host kernel isolation on a per-user basis due to the risk of containment, with guest worker microVM threads, plus the whole thing needs to scale and also needs to pause and restore very quickly and keep track of state upon restoration, it's actually a pretty hard challenge to build on AWS with existing tools. The problem arises with any interactive AI agent environment that scales on a per-user basis, for instance, but it also applies to any scenario in which the user needs to execute untrusted arbitrary code on your infrastructure in a sandbox. Fargate isn't the secure choice in that scenario; you would instead use VPC + EC2 + Firecracker + Docker (plus S3 and many others) and use a lot of orchestration scripting and fiddling with load balancers and the like to try to get everything working and scaling. When you combine it with tracking state and also restoring quickly from a paused or suspended state, I can see reasons why this might be the right choice if you want to implement something with an interactive AI agent that isolates at the per-user or per-session layer from the host kernel and is highly secured against containment escape and other vulnerabilities. I'm curious if anyone has used this for the use case described, maybe from AWS? Is this like the AgentCore orchestration that came out maybe like last year? | |||||||||||||||||||||||
| ▲ | nijave an hour ago | parent | prev | next [-] | ||||||||||||||||||||||
Pretty sure they invented Firecracker for Lambda. Iirc they were previously using a hot pool of EC2 instances behind the scenes with each customer getting their own instances and lambdas sharing capacity on an instance. Firecracker made it possible to spin up VMs in realtime instead of having spare capacity laying around. That said, Fargate does kind of seem like a superior option Edit: I guess this supports suspend and fast resume so invocation time should be somewhat better than Fargate. | |||||||||||||||||||||||
| ▲ | baxter_pad 2 hours ago | parent | prev [-] | ||||||||||||||||||||||
Fargate does not use Firecracker, it is simply ec2 instances. | |||||||||||||||||||||||
| |||||||||||||||||||||||