Anunciando Lambda MicroVMs: ambientes de computação Serverless com isolamento em nível de VM e inicialização quase instantânea

Por Ayush Kulkarni, Janak Agarwal e Tarun Rai Madan, AWS Lambda.

Recentemente anunciamos o lançamento do AWS Lambda MicroVMs, uma nova primitiva de computação Serverless que fornece isolamento em nível de VM, desempenho de inicialização quase instantâneo e retenção de estado. Agora você pode dar a cada usuário ou trabalho seu próprio ambiente de execução para executar código just-in-time com segurança – seja gerado por usuário ou IA – sem gerenciar infraestrutura de virtualização ou escolher entre isolamento, velocidade e retenção de estado. Lambda MicroVMs são alimentados pela virtualização Firecracker, a tecnologia que sustenta o AWS Lambda. Você pode usar Lambda MicroVMs para construir aplicações de análise de dados, sandboxes de IA, scanners de vulnerabilidade e ambientes de desenvolvimento interativos.

Evolução da computação Serverless

Quando lançamos o AWS Lambda em 2014, a premissa era simples: dar aos desenvolvedores uma maneira de executar código sem pensar em servidores. Faça upload de um handler, configure um gatilho e deixe o serviço lidar com provisionamento de infraestrutura, escalabilidade, patches e disponibilidade. Na última década, o Lambda cresceu para processar dezenas de trilhões de requisições por mês para mais de 1,5 milhão de clientes. Por baixo dos panos, essas invocações são executadas dentro de uma microVM Firecracker gerenciada pelo Lambda – uma máquina virtual leve que combina virtualização em nível de hardware e velocidade de inicialização quase instantânea. Com o Lambda SnapStart, usamos as capacidades de snapshot do Firecracker para acelerar os tempos de inicialização retomando ambientes de execução a partir de snapshots pré-inicializados (carregando estado de memória e disco) em vez de inicializá-los a frio.

Hoje, uma classe crescente de aplicações precisa executar código fornecido por usuários ou agentes de IA just-in-time – e precisa das capacidades principais do Firecracker diretamente: isolamento de hardware, inicialização quase instantânea e retenção de estado por períodos prolongados. Alcançar isso hoje frequentemente requer construir infraestrutura personalizada que desvia equipes do desenvolvimento de aplicações principais. Temos ouvido esse tema de clientes em casos de uso e verticais de indústria:

• Ambientes de código interativos como IDEs baseadas em navegador, notebooks e plataformas de vibe-coding precisam implantar e executar código gerado por usuários em ambientes por usuário que iniciam em segundos e retêm estado – como pacotes instalados, arquivos gerados e processos em execução – entre interações.
• Plataformas de análise de dados executam consultas e notebooks fornecidos por usuários ou gerados por LLM em ambientes isolados que retêm grandes conjuntos de trabalho por longas durações – como um dia de trabalho de 8 horas – com a capacidade de retomar rapidamente após períodos de inatividade.
• Assistentes de codificação e agentes de IA executam código gerado por LLM iterativamente, enquanto retêm contexto entre iterações, e lançam e encerram ambientes rapidamente para avaliar caminhos de código alternativos, como para aprendizado por reforço.
• Scanners de segurança de TI executam avaliações de vulnerabilidade em ambientes de computação fortemente isolados uns dos outros, podem escalar para lidar com picos de requisições de scan concorrentes e suportam privilégios elevados do sistema operacional.
• Plataformas de CI/CD precisam de ambientes de build e teste efêmeros e isolados que iniciam rapidamente e podem ser descartados após cada execução.

Apresentando Lambda MicroVMs

Agora, com o AWS Lambda MicroVMs, desenvolvedores podem usar diretamente o isolamento, velocidade e snapshot de estado da MicroVM Firecracker como uma primitiva, mantendo a simplicidade Serverless do AWS Lambda. Lambda MicroVMs fornecem essas capacidades principais.

1. Inicialização quase instantânea baseada em snapshot: Para otimizar a velocidade de inicialização, MicroVMs são lançadas a partir de imagens de MicroVM, que são snapshots Firecracker pré-inicializados do estado de memória e disco da sua aplicação. Quando você cria uma imagem de MicroVM, o serviço executa seu Dockerfile, inicializa sua aplicação e tira um snapshot da MicroVM. O Lambda inicia MicroVMs a partir deste snapshot com suas dependências carregadas.
2. Conectividade HTTPS direta: Cada MicroVM expõe um endpoint HTTPS dedicado para conectividade de entrada para portas individuais. Você pode se conectar a aplicações executando dentro da sua MicroVM usando clientes HTTPS padrão, conexões WebSocket ou gRPC – exatamente como faria com um container ou VM.
3. Controle de ciclo de vida com retenção de estado: Lambda MicroVMs permitem que você controle o ciclo de vida de cada ambiente de execução, permitindo que você suporte interações que duram alguns minutos a sessões que abrangem 8 horas.
4. Escalabilidade vertical e horizontal: Cada MicroVM inicia com uma linha de base configurável — 2 GB de memória e 1 vCPU por padrão (até 8 GB e 4 vCPUs), com CPU alocada em uma proporção de 2:1 para memória. A partir dessa linha de base, MicroVMs escalam verticalmente em até 4x automaticamente, atendendo demandas de recursos de pico para cada usuário ou sessão sem qualquer ação de sua parte. MicroVMs também escalam horizontalmente — você pode lançar várias centenas em um minuto durante picos de tráfego. Para detalhes sobre limites de serviço, consulte cotas de serviço do Lambda.
5. Acesso à Internet e VPC: Por padrão, Lambda MicroVMs suportam conectividade de saída para a internet pública sem configuração adicional. Para conectividade VPC privada a recursos como bancos de dados ou APIs internas, você pode usar um Lambda Network Connector (LNC). LNC é um novo recurso do Lambda que fornece conectividade de rede gerenciada e configurável entre suas MicroVMs e sua VPC privada.

Construindo com Lambda MicroVMs

Lambda MicroVMs introduz dois tipos de recursos principais: uma imagem de MicroVM – um artefato versionado contendo seu ambiente de runtime e código de aplicação, e MicroVMs – instâncias individuais lançadas sob demanda a partir de uma imagem de MicroVM.

Vamos tornar isso concreto com um exemplo. Você é um arquiteto de nuvem construindo uma aplicação de análise de dados que, por baixo dos panos, gerencia ambientes de computação para gerar insights para analistas de dados dentro de sua organização. Analistas carregam conjuntos de dados de múltiplos gigabytes e geram visualizações em sessões que duram horas com intervalos ociosos quando eles mudam para outras tarefas. Quando os analistas retornam, eles esperam retomar exatamente de onde pararam. Veja como você pode usar MicroVMs para essa carga de trabalho:

Passo 1: Defina seu ambiente

Escreva um Dockerfile que instala sua pilha de ciência de dados. Isso é executado uma vez no momento de build da imagem de MicroVM – a MicroVM de cada analista inicia com essas dependências já carregadas. Este Dockerfile constrói um servidor de notebook que aceita requisições de execução de código, as executa em processo (para que o estado se acumule entre requisições) e retorna resultados. Sua UI voltada ao cliente chama este servidor de notebook para cada analista.

FROM public.ecr.aws/lambda/microvms:al2023-minimal

# Install Python 3.12 and pip
RUN dnf install -y python3.12 python3.12-pip && dnf clean all

RUN pip3.12 install --no-cache-dir \
    pandas numpy scipy scikit-learn matplotlib seaborn \
    fastapi uvicorn boto3 pyarrow

COPY notebook_server.py /app/notebook_server.py
WORKDIR /app
EXPOSE 8080

CMD ["python3.12", "notebook_server.py"]

Em seguida, empacote e faça upload dos artefatos da sua aplicação e Dockerfile para o S3.

zip -r notebook-env.zip Dockerfile notebook_server.py
aws s3 cp notebook-env.zip s3://amzn-s3-demo-analytics-platform/artifacts/notebook-env.zip --region us-east-1

Com isso em vigor, crie uma imagem de MicroVM:

aws lambda-microvms create-microvm-image \
    --name analytics-notebook \
    --code-artifact '{"uri": "s3://amzn-s3-demo-analytics-platform/artifacts/notebook-env.zip"}' \
    --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
    --build-role-arn arn:aws:iam::123456789012:role/NotebookBuildRole \
    --resources '[{"minimumMemoryInMiB": 4096}]' \
    --region us-east-1

Quando você cria uma imagem de MicroVM, o Lambda executa seu Dockerfile, inicia sua aplicação e tira um snapshot Firecracker do ambiente totalmente inicializado com as bibliotecas importadas e o servidor de notebook escutando. Cada MicroVM lançada a partir desta imagem pula esta etapa de inicialização e fornece inicialização quase instantânea.

Passo 2: Lance uma MicroVM quando um analista iniciar sua sessão

Uma vez que sua imagem de MicroVM esteja pronta, você pode iniciar uma nova MicroVM para cada sessão de analista. A política de ociosidade codifica sua lógica de negócio: suspensão automática após 5 minutos de inatividade, retenção do estado suspenso por até 8 horas (cobre um dia de trabalho completo) e retomada automática quando a próxima requisição do analista chegar. Em segundos, o analista tem um ambiente dedicado com seu próprio sistema de arquivos e um endpoint HTTPS dedicado.

aws lambda-microvms run-microvm \
    --image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:analytics-notebook \
    --image-version 1.0 \
    --idle-policy '{"maxIdleDurationSeconds":300,"suspendedDurationSeconds":28800,"autoResumeEnabled":true}' \
    --maximum-duration-in-seconds 28800 \
    --execution-role-arn arn:aws:iam::123456789012:role/notebook-exec-role \
    --region us-east-1

# MicroVM endpoint url is returned by the run-microvm API call
ENDPOINT="https://a1b2c3d4-e5f6-7890-abcd-1234567890ef.lambda-microvm.us-east-1.on.aws"

Quando um analista de dados submete uma consulta, ela é submetida como uma requisição HTTPS para sua MicroVM atribuída. Você pode testar isso usando curl no endpoint da MicroVM.

curl -X POST "$ENDPOINT/execute" \
    -H "X-aws-proxy-auth: $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"code": "import pandas as pd; df = pd.read_parquet(\"s3://amzn-s3-demo-data-lake/transactions.parquet\"); print(f\"Loaded {len(df)} rows, {df.memory_usage(deep=True).sum()/1e9:.1f} GB\")"}'

Observe que você pode separar a função IAM de tempo de build da função IAM de tempo de execução para controle mais refinado sobre as permissões de cada tenant.

Passo 3: Suspenda e retome durante períodos ociosos

Após 5 minutos de inatividade, a MicroVM é automaticamente suspensa com base na política de ociosidade configurada. Quando a MicroVM é suspensa, seu estado de memória e disco é preservado.

Duas horas depois, o analista retorna e envia a próxima consulta. A MicroVM retoma automaticamente em segundos. O estado de memória e disco é restaurado exatamente como o analista os deixou – sem recomputação ou recarregamento necessário.

Analistas também podem suspender e retomar suas MicroVMs diretamente usando as APIs.

aws lambda-microvms suspend-microvm \
    --microvm-identifier microvm-a1b2c3d4-e5f6-7890-abcd-1234567890ef \
    --region us-east-1

aws lambda-microvms resume-microvm \
    --microvm-identifier microvm-a1b2c3d4-e5f6-7890-abcd-1234567890ef \
    --region us-east-1

Passo 4: Conecte-se a fontes de dados privadas

Se seus dados residem em uma VPC privada, por exemplo, clusters Amazon Redshift ou bancos de dados RDS, você pode usar um Lambda Network Connector (LNC) para dar às suas MicroVMs de analistas acesso a esses dados. Crie um conector de rede uma vez:

aws lambda-core create-network-connector \
    --name analytics-vpc \
    --configuration '{"VpcEgressConfiguration":{"SubnetIds":["subnet-data1","subnet-data2"],"SecurityGroupIds":["sg-analytics"],"NetworkProtocol":"IPv4","AssociatedComputeResourceTypes":["MicroVm"]}}' \
    --operator-role arn:aws:iam::123456789012:role/ConnectorRole \
    --region us-east-1

Em seguida, referencie-o ao iniciar uma MicroVM. Reutilize conectores de rede em todas as MicroVMs que compartilham a mesma configuração de rede.

aws lambda-microvms run-microvm \
    --image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:analytics-notebook \
    --egress-network-connectors '["arn:aws:lambda:us-east-1:123456789012:network-connector:analytics-vpc"]' \
    --idle-policy '{"maxIdleDurationSeconds":300,"suspendedDurationSeconds":28800,"autoResumeEnabled":true}' \
    --region us-east-1

Agora, os analistas da sua organização podem consultar bancos de dados privados diretamente de seu ambiente de notebook.

Passo 5: Limpeza

Para parar de incorrer em cobranças, encerre quaisquer MicroVMs em execução e exclua recursos não utilizados.

# Terminate the MicroVM
aws lambda-microvms terminate-microvm \
    --microvm-identifier microvm-a1b2c3d4-e5f6-7890-abcd-1234567890ef \
    --region us-east-1

# Delete the network connector (if created)
aws lambda-core delete-network-connector \
    --identifier analytics-vpc \
    --region us-east-1

# Delete the MicroVM image
aws lambda-microvms delete-microvm-image \
    --image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:analytics-notebook \
    --region us-east-1

Para recapitular, com MicroVMs construímos uma imagem uma vez, lançamos MicroVMs isoladas por usuário ou trabalho, interagimos via HTTPS, suspendemos quando ociosas e encerramos quando concluídas. Este padrão se aplica amplamente, em casos de uso. Por exemplo, uma plataforma de segurança de TI que escaneia repositórios de clientes tem requisitos semelhantes: um ambiente isolado por scan, a capacidade de executar com privilégios elevados do sistema operacional e escalabilidade horizontal rápida para centenas de scans concorrentes. Da mesma forma, um assistente de codificação de IA precisa de sandboxes por desenvolvedor que retêm pacotes instalados e arquivos gerados entre ciclos iterativos de escrever-testar código, com suspensão/retomada preservando contexto quando desenvolvedores mudam de tarefas. Em cada caso, o fluxo de trabalho é o mesmo.

Construindo MicroVMs com Agent Toolkit for AWS

Na seção anterior, demonstramos as operações principais da API do Lambda MicroVMs. Você também pode usar suas ferramentas de desenvolvimento Agentic preferidas para começar a desenvolver com Lambda MicroVMs. Simplesmente instale a skill AWS Lambda MicroVMs do console Lambda MicroVMs, ou use o Agent Toolkit for AWS.

Para começar no console do AWS Lambda, escolha o botão destacado para acessar as instruções do agente MicroVMs como na Figura 1:

Em seguida, copie as instruções de instalação do agente e cole-as em seu terminal para começar a desenvolver.

A captura de tela a seguir demonstra a skill em ação em um assistente de codificação de IA. Usando a skill, o agente assistente de codificação gera um plano detalhado para construir a solução de notebook de análise, executa o plano e valida a execução correta.

Lambda MicroVMs como sandboxes para Claude Managed Agents

Você também pode usar AWS Lambda MicroVMs como um provedor de sandbox gerenciado para sandboxes auto-hospedados do Claude Managed Agents. Este padrão mantém a orquestração dentro do seu ambiente Anthropic, que hospeda o loop do agente e o modelo Claude, mas move a execução de ferramentas para AWS Lambda MicroVMs, para que o código, sistema de arquivos e saída de rede do agente nunca deixem a infraestrutura que você controla. Você controla o ambiente de execução – o que está instalado, qual acesso de rede está disponível e quais recursos o agente pode alcançar. Para detalhes de integração, consulte o guia do desenvolvedor do Lambda MicroVMs.

Considerações de compatibilidade de snapshot

Lambda MicroVMs são iniciadas a partir de snapshots de estado de memória e disco pré-inicializados. Isso tem algumas implicações para como você constrói aplicações:

Unicidade: Conteúdo gerado e retido dentro de uma imagem de MicroVM é compartilhado entre todas as MicroVMs iniciadas a partir dessa imagem. Para manter unicidade para conteúdo como IDs únicos, secrets ou seeds aleatórias, gere esses valores após cada MicroVM ser iniciada. Se seu código de aplicação usa OpenSSL, use a imagem de container base fornecida pela AWS de public.ecr.aws/lambda/microvms:al2023-minimal para construir sua imagem de MicroVM.

Credenciais efêmeras e conexões de rede: Credenciais e conexões estabelecidas durante a criação da imagem de MicroVM – ou antes de uma MicroVM ser suspensa – podem expirar ou terminar no momento em que a MicroVM inicia ou retoma. Projete sua aplicação para atualizar essas credenciais e restabelecer conexões na inicialização. Clientes do AWS SDK restabelecem conexões automaticamente na maioria dos casos.

Lambda MicroVMs fornece hooks de ciclo de vida que são executados quando uma MicroVM é iniciada ou retomada. Use esses hooks para restaurar unicidade e para restabelecer conexões de rede ou credenciais efêmeras. Para mais detalhes, consulte a seção Trabalhando com snapshots no guia do desenvolvedor do Lambda MicroVMs.

Preços

Os preços do Lambda MicroVMs compreendem computação, snapshots e transferência de dados (às taxas padrão da AWS, incluindo dados transferidos para sua VPC). Você tem duas alavancas de gerenciamento de custos: faturamento de linha de base mais consumo e suspensão por ociosidade. Com o faturamento de linha de base mais consumo, sua conta acompanha mais de perto seu uso real de recursos em vez do uso de recursos de pico. Você configura a alocação de recursos de linha de base da sua MicroVM para corresponder à utilização média de recursos da sua carga de trabalho – não o pico. Durante atividade de pico, sua MicroVM pode escalar verticalmente até 4x da linha de base configurada automaticamente e o uso de recursos acima da linha de base é cobrado apenas durante o uso ativo. Você configura a linha de base definindo memória, e a CPU é alocada em uma proporção de 2:1 memória para CPU – o padrão é 2GB / 1vCPU, com um pico correspondente de 8 GB / 4 vCPU. Os valores de linha de base e pico suportados são mostrados na Figura 4.

Durante períodos ociosos prolongados, você pode suspender sua MicroVM para preservar o estado de memória e disco a taxas somente de armazenamento, retomando quase instantaneamente quando necessário – sem cobranças de computação enquanto suspensa. Para detalhes completos de preços, consulte preços do AWS Lambda.

Conclusão

Lambda MicroVMs estende o modelo de computação Serverless além de funções baseadas em invocação para ambientes de longa duração e com estado que executam código fornecido por usuários finais ou IA. Equipes de desenvolvimento podem se concentrar no desenvolvimento de aplicações principais enquanto o Lambda fornece isolamento seguro e desempenho de inicialização quase instantâneo. Seja você construindo um assistente de codificação de IA, uma plataforma de desenvolvimento interativa, uma plataforma de segurança de TI ou uma carga de trabalho de análise de dados, o padrão é o mesmo: defina seu ambiente em um Dockerfile, construa uma Imagem de MicroVM uma vez, lance MicroVMs isoladas sob demanda, interaja via HTTPS e encerre quando concluído.

Para começar, visite o guia do desenvolvedor do AWS Lambda MicroVMs ou comece a construir com a skill de agente MicroVMs, disponível através do console do AWS Lambda.

Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.

Autores

Tradutores

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/

Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Atualmente está habilitando empresas do ramo de ISV (Independent Software Vendors) simplificando a operação na nuvem e otimizando os custos em cloud. Sua área de interesse são tecnologias serverless. https://www.linkedin.com/in/nicolastarzia