AWS представила MicroVM для безопасного запуска кода ИИ с экономией затрат

Unlocking Efficiency: A Conversation on AWS Lambda MicroVMs This Q&A has been edited for length and clarity. David Rubinstein: To start, this project launched a couple of months ago. Rather than getting into the nuts and bolts of the initial announcement, I want to understand the “second day” angle—what was the need that prompted this development? Barry Cooks: Maybe I’ll start with the landscape of abstractions. We have a broad set of abstractions that solve a lot of problems—Kubernetes, ECS, and Lambda. But with the state of AI and the amount of newly generated, and I’ll say untrusted code being executed, customers wanted a high trust model. They wanted better isolation. They don’t want things running side by side that are potentially adversarial or just not understood. That model lends itself well to MicroVMs and Firecracker, the underlying technology. David Rubinstein: So, this isn’t necessarily “new” technology, but rather a new application of existing internal tools? Barry Cooks: Exactly. If you were to peel the cover back on Lambda, deep down in the bowels, you would find this is exactly how we run Lambda. It’s how we’ve been doing things for a decade. But one of the things MicroVMs set out to solve is the need for persistence. Lambda is specialized for event-based architectures, but we have workloads that need to stick around longer and are stateful. MicroVMs take those internal learnings and give them to customers, providing a firm, hardware-enforced security boundary. You can trust that you can run untrusted LLM code in there, compartmentalized away from the rest of your stack. David Rubinstein: You also mentioned addressing latency. Many people experience that lag when waiting for the first token back from an AI model. How does this help? Barry Cooks: One of the challenges was, how can we make this go faster? With MicroVMs, we take your container image, start it up, and then checkpoint you in your ready state. We store you off, and as that first workload comes in, we can get you up in an incredibly fast, near-instant timeframe. It reduces that latency tremendously. Plus, we structured MicroVMs so you’re only paying for what you use. If you go idle, we checkpoint you off so you aren’t paying for compute you don’t need. David Rubinstein: That sounds like a significant cost control. Is that a primary benefit? Barry Cooks: It is. We know costs can run out of control. It’s a land rush in the new AI market, and often when land rushes happen, people jump in with both feet only to realize it’s an expensive jump. We are trying to stay ahead of that by fitting cost optimization into the model at day one. David Rubinstein: And clarify for me—is there AI underlying the implementation itself? Barry Cooks: The implementation itself is traditional. I always worry about “AI washing,” where people claim everything is AI-driven when it doesn’t need to be. Our idle detection is driven by traffic observation—it’s a straightforward timer. We are always looking for opportunities to use AI to build products faster and more securely, but for this, we want to keep it clean and simple. David Rubinstein: It seems like a disciplined approach to a high-growth area. Barry Cooks: Exactly. We’ve earned our battle scars. We don’t want to throw out the lessons we learned the hard way just because there’s a new trend. We want to leverage those learnings to provide the best tools for the job.