Forem: Giovana Armani

Lambda Durable Functions: Como construir aplicações multi-etapas com um único serviço

Giovana Armani — Wed, 08 Apr 2026 12:31:20 +0000

Sempre quis rodar processos longos em uma função Lambda sem se preocupar com o limite de 15 minutos? E executar processos com múltiplos passos sem sair do lugar? Não diga mais nada! Conheça AWS Lambda Durable Functions...

Complexidade de workflows: um problema conhecido

Quem já trabalhou com sistemas baseados em workflows sabe que é uma tarefa que pode ficar complexa bem rapidamente.

Você começa definindo a sequência de instruções que precisa seguir. É fácil pensar no clássico caminho feliz quando tudo dá certo, mas a coisa começa a complicar quando lembramos que sistemas falham...

A cada passo, você precisa registrar o estado da sua aplicação para saber exatamente o que já foi executado. Se algo falha, você precisa garantir que é seguro dar um retry. Passos já completos devem ser pulados e se forem reexecutados, devem produzir o mesmo resultado sempre. Essa propriedade se chama idempotência. Ela que garante que uma re-execução não vai causar duplicações ou inconsistências no sistema.

Existem serviços de orquestração de workflows que simplificam esse processo de maneira visual, como o AWS Step Functions. Mas esses também trazem seus desafios porque o lugar onde os passos são declarados é diferente de onde são implementados. A definição do workflow fica em um arquivo JSON ou YAML e a implementação mora no código. Isso torna mais difícil testar o caminho inteiro e as várias possibilidades já que vemos a lógica toda distribuída.

Isso tudo sem contar a complexidade de administrar vários serviços separados. Quem nunca se perdeu ao tentar administrar e monitorar várias funções Lambda ao mesmo tempo que atire a primeira pedra...

Lambda Durable Functions traz uma alternativa para criar e administrar workflows de maneira serverless de forma simplificada dentro do próprio código, centralizando tudo em uma mesma função.

O que é AWS Lambda Durable Functions?

Lambda Durable Functions é uma funcionalidade do AWS Lambda. Ela permite criar e executar workflows dentro de uma função lambda diretamente pelo código da função. No momento, a funcionalidade está disponível para Node.js a partir da versão 22.x e Python a partir da versão 3.13. A funcionalidade também está em fase de Developer Preview para Java, o que significa que tem suporte para a linguagem no SDK, mas só pode ser criada através de uma imagem de contêiner.

Sendo uma funcionalidade do AWS Lambda, Durable Functions naturalmente entra como parte do universo serverless. Isso significa que podemos implementar as funcionalidades de um workflow como checkpoints, retries, pausa e retorno sem administrar instâncias de servidores!

Como criar uma Durable Function

Para ter uma função Lambda com Durable Functions, é preciso habilitar essa funcionalidade desde sua criação. Não é possível alterar uma função já existente para ser uma função durável. Conseguimos criá-la pelo console, pela CLI ou usando infraestrutura como código.

No console, isso é feito habilitando a execução durável na página de criação como demonstrado abaixo.

Para criar através da CLI, rodamos o comando de criação com o atributo durable-config.

aws lambda create-function \
  --function-name minha-funcao-duravel \
  --runtime python3.14 \
  --role arn:aws:iam::<numero_da_conta_aws>:role/minha-funcao-duravel-role \
  --handler lambda_function.lambda_handler \
  --zip-file fileb://function.zip \
  --durable-config '{"ExecutionTimeout": 3600, "RetentionPeriodInDays": 7}'

Esse atributo aceita dois parâmetros opcionais de configuração da Durable Function:

ExecutionTimeout - tempo máximo em segundos que a execução durável inteira pode durar, incluindo tempos de pausa e retry. O tempo máximo é de 1 ano
RetentionPeriodInDays - número de dias que o histórico das execuções duráveis são armazenados depois de serem finalizados

Observação: o comando acima de criação de função Lambda é um exemplo ilustrativo. Para executá-lo com sucesso, seria preciso criar a role do IAM chamada "minha-funcao-duravel-role" e ter um zip chamado "function.zip" contendo o código da função.

De forma parecida, podemos criar Lambda Durable Functions usando infraestrutura como código. Fazemos isso através do CloudFormation, um serviço da AWS que permite criar e gerenciar sua infraestrutura na nuvem utilizando templates JSON ou YAML. Existem ainda ferramentas como AWS CDK e Terraform que auxiliam nessa criação permitindo usar linguagens de programação. Em um template de CloudFormation, a Durable Function também apresenta o atributo de DurableConfig:

Resources:
  MyDurableFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: minha-funcao-duravel
      Runtime: python3.14
      Handler: lambda_function.lambda_handler
      Code:
        ZipFile: fileb://function.zip
      DurableConfig:
        ExecutionTimeout: 3600
        RetentionPeriodInDays: 7

Como funciona?

Vamos imaginar como exemplo uma aplicação de criação de ordem de compra. Um funcionário cria a ordem de compra, então o sistema verifica no inventário se os itens solicitados estão disponíveis. Caso estejam, alguns gerentes responsáveis são notificados para revisar e aprovar a compra e, se aprovarem, a ordem é confirmada.

Quando uma função Lambda está habilitada como uma Durable Function, dizemos que ela permite uma durable execution (execução durável) e cada etapa do workflow é um durable step (passo durável). Isso significa que a função consegue "lembrar" o estado em que estava no caso de falhas ou pausas e retomar a execução a partir desse ponto.

Veja no diagrama abaixo como poderíamos representar os passos da aplicação de ordem de compra:

Existem alguns conceitos fundamentais para administração de workflows que aparecem nas Durable Functions.

Checkpoint e replay

Veja abaixo o nosso exemplo como estrutura de um código de uma Lambda Durable Function em Python:

@durable_step
def create_order(step_context: StepContext, order_data: dict) -> dict:
    # Implementação da criação de ordem

@durable_step
def check_inventory(step_context: StepContext, order_data: dict) -> dict:
    # Implementação da checagem de inventário

@durable_step
def notify_approver(step_context: StepContext, callback_id: str, approver: dict) -> dict:
    # Implementação da notificação de gestores

@durable_step
def confirm_order(step_context: StepContext, order_id: str) -> dict:
    # Implementação da confirmação de ordem

@durable_execution
def lambda_handler(event: dict, context: DurableContext) -> dict:
    # Chamada e orquestração dos steps

Note que o handler da função Lambda, ou seja, seu ponto de entrada, é anotado com @durable_execution. Cada um dos steps é anotado com @durable_step. Após a execução de cada um dos steps, é feito um checkpoint automático que registra o resultado de cada passo. Caso a função seja pausada (veremos isso numa próxima seção) e retome, ela será reexecutada do início, steps já completos serão pulados e a função usará os resultados já armazenados. Chamamos essa retomada de replay.

Retry

Diferentemente do replay que acontece quando o código é pausado, o retry acontece na falha. Quando uma exceção ocorre dentro de um step, ele será automaticamente retentado. É possível também declarar sua própria estratégia de retry como eu faço abaixo no step de criação de ordem:

@durable_execution
def lambda_handler(event: dict, context: DurableContext) -> dict:
    # Recebe dados da ordem através do evento enviado para a função
    order_data = event["order"]

    retry_config = RetryStrategyConfig(max_attempts=5, backoff_rate=2.0) # Configuração personalizada de retry
    order = context.step(
        create_order(order_data),
        config=StepConfig(retry_strategy=create_retry_strategy(retry_config)),
    )

Wait

É possível fazer com que sua função espere um determinado tempo antes de executar uma próxima instrução. No nosso exemplo, vamos imaginar que queremos que a função espere um tempo depois da criação da ordem para checar o inventário.

@durable_execution
def lambda_handler(event: dict, context: DurableContext) -> dict:
    order_data = event["order"]

    order = context.step(create_order(order_data))

    context.wait(Duration.from_minutes(5)) # Espera por 5 minutos

    inventory_check = context.step(check_inventory(order_data))

    # Restante da implementação

Durante o tempo de espera, a função está pausada, então não serão feitas cobranças por esse período. O timeout máximo de uma invocação individual de uma função Lambda continua sendo 15 minutos, mas a durable execution pode durar até 1 ano!

Callback

Além de querer pausar nossa execução por um tempo específico, podemos querer pausar até obter uma resposta de um serviço externo ou até mesmo de um usuário, como é o caso da aprovação dos gestores no nosso exemplo. Essa estratégia de resposta assíncrona é chamada de callback.

Quando chamamos a função create_callback do SDK, geramos um identificador único (o callback_id) que enviamos para o sistema ou pessoa que precisa responder. A função então pausa no callback.result() sem consumir recursos até que a resposta chegue. Portanto, assim como no caso do wait, não recebemos cobrança durante esse período de espera.

Vamos ver como ficaria a aprovação de um único gestor:

@durable_execution
def lambda_handler(event: dict, context: DurableContext) -> dict:
    # Chamada de passos anteriores
    approvers = event["approvers"]  # [{"name": "Ana"}, {"name": "Júlia"}, {"name": "Bruno"}]

    # Cria o callback com timeout de 24 horas
    callback = context.create_callback(
        name="approval-manager",
        config=CallbackConfig(timeout=Duration.from_hours(24)),
    )

    context.step(notify_approver(callback.callback_id, approvers[0]))

    approval_result = callback.result()

    # Restante da implementação

Para responder, o sistema ou pessoa deve chamar a API SendDurableExecutionCallbackSuccess do Lambda. O gestor poderia usar um outro sistema com sua própria função Lambda que chama essa API do sistema de criação de ordem para notificar a aprovação. Em código teríamos:

def lambda_handler(event, context):
    lambda_client = boto3.client("lambda")
    callback_id = event["callback_id"]
    approved = event.get("approved", True)

    # Mandando callback de sucesso
    if approved:
        lambda_client.send_durable_execution_callback_success(
            CallbackId=callback_id,
            Result=b'{"approved": true}',
        )
    # Mandando callback de erro
    else:
        lambda_client.send_durable_execution_callback_failure(
            CallbackId=callback_id,
            Error={"ErrorType": "Rejected", "ErrorMessage": "Approver rejected the order"},
        )

    return {"statusCode": 200, "body": "Callback sent"}

Parallel

Vimos como configuraríamos para esperar a resposta de um gestor, mas no nosso exemplo, a ordem de compra precisa ser aprovada por vários gestores. Ao invés de enviar um callback de cada vez e esperar sequencialmente, podemos usar context.parallel para enviar todos ao mesmo tempo. Isso gera uma branch (ramificação) para cada chamada que roda de forma independente com seu próprio checkpoint.

No código abaixo, cada gestor recebe seu próprio callback e a função espera todas as respostas chegarem antes de continuar:

@durable_execution
def lambda_handler(event: dict, context: DurableContext) -> dict:
    # Chamada de passos anteriores

    approvers = event["approvers"]  # [{"name": "Ana"}, {"name": "Júlia"}, {"name": "Bruno"}]

    def request_approval(approver: dict, ctx: DurableContext) -> dict:
        # Cria um callback para cada gestor
        callback = ctx.create_callback(
            name=f"approval-{approver['name']}",
            config=CallbackConfig(
                timeout=Duration.from_hours(24),
                heartbeat_timeout=Duration.from_hours(1),
            ),
        )

        # Notifica o gestor com o callback_id
        ctx.step(notify_approver(callback.callback_id, approver))

        # Pausa até o gestor responder
        approval = callback.result()
        return {"approver": approver["name"], "decision": approval}

    # Executa todas as aprovações em paralelo
    approval_results = context.parallel(
        [
            lambda ctx, a=approver: request_approval(a, ctx)
            for approver in approvers
        ],
        name="send-approvals",
    )

    # Restante da implementação

Se Ana responder em 5 minutos e Bruno demorar 2 horas, a função continua pausada sem custo até que todos respondam. Cada branch tem seus próprios checkpoints, então se uma falhar, as outras não são afetadas.

Cálculo de preço

A cobrança de uma Durable Function é composta por quatro componentes:

Cobranças padrão do Lambda — as mesmas cobranças de requests e duração de qualquer função Lambda: $0.20 a cada 1 milhão de requisições mais o valor por duração das execuções que varia de acordo com a arquitetura da função ($0.0000166667 por GB-segundo para arquitetura x86 e $0.0000133334 por GB-segundo para ARM/Graviton2) Isso inclui sub-invocações geradas por replays. Durante operações de wait ou callback, funções on-demand não geram cobrança de duração já que a execução está suspensa.
Operações duráveis — cada operação durável (iniciar uma execução, completar um step, criar um wait, etc.) é cobrada individualmente. O preço na região US East (N. Virginia) é de $8.00 por milhão de operações.
Dados escritos — os dados persistidos pelos checkpoints (payloads de steps, waits, callbacks) são cobrados por GB escrito. O preço é de $0.25 por GB.
Retenção de dados — os dados dos checkpoints são armazenados durante a execução e após sua finalização. A cobrança é de $0.15 por GB-mês, proporcional ao tempo de armazenamento. O período de retenção após a conclusão é configurável de 1 a 90 dias (padrão: 14 dias).

Para mais informações sobre preço, consulte a página de preços do AWS Lambda e a calculadora de preços da AWS.

Diferença entre Lambda Durable Functions e Step Functions

Se você já conhece a AWS, provavelmente está se perguntando: "mas isso não é o que o Step Functions faz?". Boa pergunta! Os dois serviços resolvem o mesmo problema, mas de formas bem diferentes.

A principal diferença está em onde o workflow é definido. No Step Functions, você declara o fluxo usando um arquivo JSON chamado ASL (Amazon States Language). Cada estado e transição é definido nesse arquivo, separado do código que executa a lógica. Cada passo do Step Functions pode chamar uma função Lambda, outro serviço de compute, ou até mesmo fazer uma chamada de serviço diretamente, como chamar o Dynamo ou uma fila, por exemplo.

Já com Durable Functions, o workflow inteiro mora no código da função Lambda. Você escreve a sequência de passos como código normal e o SDK cuida do resto.

Ambos são modelos de orquestração, ou seja, existe um coordenador central que controla o fluxo e sabe qual é o próximo passo. A diferença é que no Step Functions o orquestrador é a máquina de estados que é demonstrada de forma visual no console da AWS e no Durable Functions o orquestrador é o próprio código do handler.

Veja na tabela abaixo um comparativo entre os dois serviços:

	Step Functions	Durable Functions
Definição do workflow	Declarativa (ASL JSON/YAML), separada do código	Imperativa, dentro do código da função
Gerenciamento de estado	Gerenciado pelo serviço através de transições de estado	Gerenciado pelo SDK através de checkpoints
Visibilidade da execução	Console visual com diagrama do fluxo e histórico de execução	Aba "Durable executions" no console do Lambda + Logs
Integrações nativas	Mais de 200 integrações diretas com serviços AWS sem precisar de código	Integrações feitas via SDK dentro de steps no código
Melhor para	Fluxos complexos com muitas integrações AWS e equipes que preferem workflows visuais, como equipes voltadas a negócios	Fluxos com foco no programa, equipes técnicas que preferem manter tudo no código

Uma vantagem prática do Durable Functions é que como tudo está no código, fica mais fácil testar o fluxo inteiro localmente. Com Step Functions, testar o workflow completo geralmente exige deployar a máquina de estados e as funções Lambda separadamente, o que adiciona complexidade no ciclo de desenvolvimento.

Por outro lado, Step Functions brilha quando você precisa de integrações diretas com serviços AWS sem escrever código para cada chamada, ou quando a visibilidade visual do fluxo é importante para a equipe.

Conclusão

Nesse artigo, vimos como Lambda Durable Functions permite construir workflows multi-etapas diretamente no código de uma função Lambda. Passamos pelos conceitos de durable execution, steps, checkpoints e replay, e vimos na prática como funcionalidades como wait, callbacks e execução paralela se traduzem para código em um exemplo de criação de ordem de compra.

Também entendemos como Durable Functions se compara ao Step Functions: ambos orquestram processos, mas com modelos mentais diferentes.

Como próximo passo, que tal experimentar reproduzir o exemplo desse artigo na sua própria conta? Você pode testar usando uma conta Free Tier da AWS! Ela permite que você explore serviços AWS com até 200 dólares de créditos por um período de 6 meses. Você não será cobrado a não ser que explicitamente escolha trocar de plano. Se quiser começar a pensar em problemas de fim a fim e criar sistemas serverless, deixo aqui ainda esse artigo para criar seu primeiro sistema serverless com AWS Lambda.

JavaScript e SDK: Como sua aplicação web pode falar com a nuvem

Giovana Armani — Thu, 26 Mar 2026 19:29:54 +0000

Em artigos passados, falei sobre o que é SDK e por que ele é importante e construímos uma aplicação back-end para conversão de documentos usando o SDK da AWS. Vamos usar o SDK mais uma vez, mas agora para construir nosso front-end!

O que é SDK mesmo?

Podemos pensar SDK (Software Development Kit) como uma caixa de ferramentas para construir aplicações sobre uma plataforma, sistema operacional ou linguagem de programação. Ele pode incluir bibliotecas, APIs, documentação, exemplos de código, debuggers, entre outras coisas. Caso queira saber mais sobre SDK e sua diferença para APIs e bibliotecas, veja esse artigo.

O SDK da AWS para JavaScript permite fácil acesso a serviços da AWS a partir de seu código JS. Você verá como com algumas importações e comandos rápidos podemos conversar diretamente com a nuvem!

Tudo que construiremos nesse tutorial, assim como o tutorial do back-end, pode ser reproduzido com uma conta Free Tier da AWS. Com ela, você ganha 100 dólares em créditos na conta e pode ganhar até 100 dólares adicionais ao explorar os diferentes serviços da AWS e não será cobrado a não ser que explicitamente escolha trocar de plano. Se quiser saber mais sobre como criar sua conta e as melhores configurações de segurança, veja esse artigo.

O que vamos construir

No nosso backend, temos uma função Lambda que converte arquivos CSV para JSON. Ela é acionada quando colocamos um arquivo no bucket S3 de input e coloca os arquivos convertidos em um outro bucket do S3 de output. Como queremos fazer o front-end para essa aplicação, vamos construir uma tela que rodará no navegador. Ela será dividida em duas partes: uma seção para fazer o upload de arquivos CSV e outra para o download dos arquivos JSON.

Primeiros passos: rodando a página web

Para esse projeto, vamos usar React, uma biblioteca do JavaScript para criação de interfaces. Para isso, é preciso ter o node.js. Caso não tenha node na sua máquina, comece baixando no site oficial. Selecione "Get Node.js" para baixar.

Nesse repositório você encontrará o código completo do front-end na pasta "front", assim como o back-end que já construímos. Para começar a reproduzir a aplicação, clone ele para editar o código. Siga os passos:

Crie uma pasta no seu computador para o projeto
No terminal, navegue até a pasta criada através do comando cd <caminho-ate-a-pasta>
Clone o repositório com o comando git clone https://github.com/gi-armani/CSV-JSON-Converter-sample-for-aws-SDK
Para rodar a aplicação, navegue até a raiz do projeto com o comando cd <caminho-ate-a-pasta-criada>/CSV-JSON-Converter-sample-for-aws-SDK/front
Execute npm install para instalar as dependências e npm start para iniciar

Você deverá ver uma mensagem parecida com a mensagem abaixo:

Agora você pode abrir http://localhost:3000/ no seu navegador de preferência e ver os elementos visuais da aplicação. Lembre-se que ela ainda não está conectada na nuvem, mas vamos cuidar disso!

Entendendo a estrutura da página

Quando iniciamos um projeto React, o principal arquivo da aplicação estará localizado em CSV-JSON-Converter-sample-for-aws-SDK/front/src/App.js que contém a seguinte estrutura:

// importação de bibliotecas, imagens e outros elementos
import logo from './logo.svg';
import './App.css';

function App() {
  // Aqui colocamos a lógica (variáveis e funções que precisaremos usar)

  return (
    // Aqui estarão os diferentes elementos do site, declarados em componentes similares ao html
  );
}

export default App;

O trecho de código acima tem indicativos de onde estarão os nossos elementos visuais (textos, inputs, botões, etc) e onde estará a lógica dos processos. Veja que no código que você clonou tudo isso já está criado, mas ainda vamos precisar substituir algumas constantes para conectar com a nuvem.

Configurando permissões

Pausando um pouco no código e indo para a conexão com a nuvem, precisamos configurar permissões para nosso código conseguir acessar os arquivos. Agora vamos conectar o front-end com o back-end que criamos anteriormente. Caso você não tenha os buckets do S3 e a função Lambda na sua conta, recomendo criá-los primeiro usando as instruções do artigo anterior.

Para isso, vamos usar o IAM (AWS Identity and Access Management). Esse é um serviço da AWS que permite controlar acesso a permissões dentro da sua conta. Se quiser entender mais sobre como funciona o IAM e os diferentes tipos de permissão, veja esse artigo.

Na minha conta AWS, estou na região de us-west-2 (Estados Unidos Oregon). É importante criar todos os seus recursos na mesma região para evitar problemas de comunicação entre eles. Você pode identificar a região que você está a qualquer momento no menu superior da conta ao lado do nome e número da conta.

Criando a política de acesso ao S3

Vamos começar criando a política de acesso, ou seja, o documento que diz o que é permitido fazer e onde.

No console da AWS da sua conta Free Tier, navegue até a página do IAM e selecione "Políticas" no menu da esquerda
Clique em "Criar política"
No canto superior direito do editor de políticas, selecione a opção JSON e cole o conteúdo abaixo. Não se esqueça de substituir os locais indicados em "Resource" com os nomes dos seus buckets

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowWriteInput",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<NOME-DO-SEU-BUCKET-DE-INPUT>/*"
        },
        {
            "Sid": "AllowReadOutput",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<NOME-DO-SEU-BUCKET-DE-OUTPUT>/*"
        },
    {
      "Sid": "AllowListOutput",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::gio-csv-converter-output"
    }
    ]
}

Aqui temos uma política que permite subir arquivos no bucket de input (operação PutObject) e ler arquivos do bucket de output (operação GetObject). Temos também uma última permissão que permite listar os objetos de um bucket (operação ListBucket). Essa última é importante porque caso a conversão do json ainda não tenha sido terminada, fará com que o S3 retorne um erro mais amigável dizendo que o arquivo ainda não existe. Sem essa permissão, o S3 retornaria um erro de acesso negado.

Na opção "Visual" do editor de políticas, é possível construir essa mesma política de forma interativa selecionando os serviços e as operações que serão usadas (deixo para a curiosidade de quem quiser explorar 😉).

Para terminar a criação, basta selecionar "Próximo", dar um nome à sua política na próxima página (chamei a minha de "jsWebClientS3Access") e então selecionar "Criar política" no canto inferior direito.

Criando um identity pool

Para essa parte, vamos usar o Amazon Cognito, um serviço da AWS de autenticação para aplicações. Ele nos ajuda a identificar quem é o usuário que está acessando nossa aplicação e gerar credenciais de acesso que são atualizadas automaticamente.

Os Identity pools (ou grupos de identidade) são diretórios de identidades que podem ser usados para obter credenciais para acessar outros serviços da AWS através do nosso front-end. Para criá-lo, siga os passos abaixo:

Na sua conta Free Tier, navegue até o Amazon Cognito
Selecione "Grupos de identidades" no menu esquerdo e em seguida "Criar grupo de identidades" no botão laranja à direita
Na página de criação, selecione "Acesso de convidado". Isso permitirá que nosso código front-end acesse os recursos que queremos sem precisar de um login. Clique em "Próxima" para continuar
Em seguida, vamos criar um perfil do IAM que usaremos para declarar as permissões. Selecione "Criar um novo perfil do IAM" e dê um nome a ele. Chamei o meu de "jsWebClientRole". Clique em "Próxima" para continuar
Dê um nome ao grupo de identidades. Chamei o meu de "jsWebClientIdentity". Clique em "Próxima" para continuar
Revise os detalhes do grupo de identidade que estamos criando e selecione "Criar grupo de identidades" para concluir.

De volta na página dos Grupos de identidade do Amazon Cognito, você verá seu grupo de identidade criado. Salve o ID dele pois será usado logo mais para autenticação no código.

Por último, precisamos ligar a política de acesso que criamos na seção anterior ao grupo de identidade:

Navegue até o console de IAM
No menu esquerdo, selecione "Funções"
Busque pelo perfil que criamos junto ao Grupo de identidade. O meu é o "jsWebClientRole"
Na aba de "Permissões", selecione "Adicionar permissões" e "Anexar políticas"
Busque pela política de acesso ao S3 que criamos anteriormente e clique em "Adicionar permissão"

Configurando CORS

Um conceito clássico que vemos quando integramos aplicações, como integração entre front e back-end, é CORS. CORS significa Cross-Origin Resource Sharing, ou compartilhamento de recursos entre origens, e é um mecanismo para compartilhar conteúdo entre diferentes domínios de forma segura. Com ele, declaramos o que pode ser compartilhado e quais domínios podem enviar conteúdo. Precisamos configurar CORS para o bucket de input e de output.

No console da AWS, navegue até a página do S3
Selecione o nome do bucket de input que criamos no último tutorial quando construímos o back-end
Clique em "Permissões" e desça até o final da página onde encontrará "Compartilhamento de recursos de origem cruzada (CORS)"
Clique em editar e cole o conteúdo abaixo:

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "PUT"
        ],
        "AllowedOrigins": [
            "http://localhost:3000"
        ],
        "ExposeHeaders": [
            "ETag"
        ]
    }
]

⚠️ Note que adicionamos especificamente o localhost na porta 3000 em "AllowedOrigins" o que significa que o bucket aceitará receber recursos apenas desse domínio. A melhor prática de segurança é sempre restringir acesso para o mínimo necessário. Para um site que estivesse deployado na internet, adicionaríamos o domínio específico da aplicação que faz o envio.

Repita os mesmos passos para habilitar CORS no bucket de output.

Conectando tudo: chamando o SDK da AWS

Agora que temos as permissões configuradas na conta AWS, vamos fazer a conexão com o S3 no código.

No começo do arquivo App.js do repositório clonado, você encontrará o seguinte trecho:

const REGION = 'us-west-2';
const IDENTITY_POOL_ID = '';

const clienteS3 = new S3Client({
  region: REGION,
  credentials: fromCognitoIdentityPool({
    clientConfig: { region: REGION }, 
    identityPoolId: IDENTITY_POOL_ID
  })
});

O IdentityPoolId usado para criar o clienteS3 será o ID do Grupo de Identidades que criamos com Amazon Cognito. Preencha esse valor na constante IDENTITY_POOL_ID. Note que a constante REGION, que indica a região, está declarada como us-west-2. Caso seus recursos estejam em outra região da AWS, mude essa constante para a região correspondente.

⚠️ Essa é a forma recomendada pela AWS para obter credenciais para o navegador. Muito cuidado com expor suas credenciais abertamente, jamais publique elas na internet!

Por fim, preencha as constantes que representam os buckets de input e output com os nomes dos seus buckets:

const BUCKET_ENTRADA = '';
const BUCKET_SAIDA = '';

Pronto! Se seu back-end também estiver configurado, você terá um sistema completo incluindo front e back-end que utiliza o SDK da AWS para comunicação com os serviços em nuvem. Você pode usar esse csv de exemplo para testar a aplicação.

Conclusão

Agora você já sabe como construir uma aplicação front-end que se comunica diretamente com serviços da AWS. Nesse tutorial, você aprendeu a:

Instalar e usar o AWS SDK para JavaScript para interagir com o S3
Configurar permissões no IAM para que sua aplicação acesse serviços da AWS de forma segura
Configurar CORS para permitir a comunicação entre seu front-end e a nuvem

Reproduza esse tutorial na sua máquina e dê seu próprio estilo ao design da página. Experimente trocar cores, fontes e layout, deixe com a sua carinha. Com o front-end e o back-end que construímos no artigo anterior, você tem uma aplicação serverless completa funcionando na AWS!

Seus primeiros passos com computação em nuvem

Giovana Armani — Fri, 13 Mar 2026 21:12:21 +0000

Não tem jeito melhor de aprender sobre computação em nuvem do que colocando a mão na massa. Venha entender do que se trata essa tecnlogia e criar uma página pessoal na nuvem (mais fácil do que você imagina)!

O que faz uma aplicação?

Uma aplicação é composta por diversas partes diferentes como vemos no diagrama abaixo:

Autenticação/autorização: a forma que uma aplicação descobre quem está tentando acessar e o que ela tem permissão de fazer
Front-end: elementos visuais da aplicação, como as telas de aplicativos
Back-end: onde acontece o processamento dos dados que são mostrados
Banco de dados: onde são guardadas informações como texto, números, datas, etc
Armazenamento de arquivos: para guardar arquivos como imagens, audios, pdfs, etc

Existem ainda vários outros componentes como serviços de rede, segurança, monitoramento, mensagerias, entre outros.

O que é computação em nuvem?

Antigamente, as empresas donas de aplicações precisavam construir do zero cada uma dessas e das várias outras partes que compõe um sistema. Para rodar as aplicações, era preciso cuidar dos próprios servidores, os super computadores que executam progamas e armazenam e transferem dados, como os mostrados abaixo. Isso acabava sendo caro porque os servidores precisam do seu próprio lugar para ser mantidos, os famosos data centers. Além disso, manter um servidor exige bastante trabalho e uma equipe tecnica especializada para mantê-los atualizados e seguros. Isso sem contar o espaço físico, eletricidade e refrigeração que essas máquinas precisam... ufa, coisa demais!

A computação em nuvem veio para revolucionar isso porque agora não é mais preciso ter seus próprios servidores e data centers. Podemos "pegar emprestado" das empresas provedoras de nuvem, como a AWS. Não só isso facilita para empresas crescerem, mas oferece aos devs a possibilidade de construir sistemas dos mais malucos sem sair do seu computador.

É comum dizermos que a computação em nuvem é a entregra sob demanda de recursos de TI através da internet, mas o que significa isso, afinal?

Os "recursos de TI" são aquelas várias partes que formam um sistema que podemos encontar na nuvem como blocos de construção de aplicações. Já quando dizemos "entrega sob demanda", significa que podemos usar os serviços em nuvem apenas enquanto precisamos e liberá-los quando não forem mais necessários.

Dessa forma, temos mais agilidade e redução de custo porque pagamos pelos recursos computacionais só enquanto estão sendo usados na nossa aplicação.

Conta Free Tier da AWS

Falando em pagamento, um grande medo dos desenvolvedores quando estão aprendendo sobre computação em nuvem e querem experimentar é não se atentar aos preços e acabar recebendo uma fatura surpresa...

Pensando nisso, a AWS lançou a conta Free Tier. Ao criá-la, você ganha 100 créditos na conta e pode ganhar até 100 créditos adicionais ao explorar os diferentes serviços da AWS e não será cobrado a não ser que expliticamente escolha trocar de plano - sem cobranças supresa! Se quiser saber mais sobre como criar sua conta e as melhores configurações de segurança veja esse artigo.

Construindo sua primeira aplicação em nuvem

Para começar a brincar com a nuvem, vamos construir uma aplicação simples, mas fundamental para qualquer desenvolvedor: um portifolio pessoal online! Construiremos um site estático e publicaremos ele na internet.

Criando a aplicação localmente

Para mostrar que você pode começar na nuvem independente do seu nível de conhecimento e momento de carreira, vou construir uma aplicação bem simples com as tecnologias que eu usava quando comecei a aprender sobre desenvolvimento: html e css.

Html é a linguagem de script que permite criar a estrutura dos sites com elementos como botões, inputs, textos. Já com CSS, configurmos o estilo da página.

Deixei abaixo um print da minha versão de página pessoal (super simples, vou incrementar com o tempo) e nesse repositório deixei o código fonte para servir de base ou inspiração para seus projetos.

Caso você queira começar rápido, é possível fazer um esboço do site em um editor de imagem e enviar para a sua IA de preferencia pendindo para ela criar o código base, eu recomendo o Kiro 😉.

Deployando a aplicação para a nuvem

Agora para subir o site na internet, vamos usar AWS Amplify. Esse é o serviço da AWS que oferece uma plataforma de desenvolvimento para criação de páginas web e móveis de forma fácil e rápida. Para subir sua aplicação, siga os passos a seguir:

Em sua conta Free Tier da AWS, navegue até o AWS Amplify
Clique em Implemente uma aplicação
Selecione Implantar sem git ou escolha a fonte de código da sua preferência
Clique em Próximo e dê um nome para sua aplicação
Compacte seus arquivos e adicione-os no console. Compacte os arquivos em si, não o diretório em que eles estão
Nomeie o zip como index.zip
Clique em Salvar e implantar. A página vai carregar por alguns segundos e te direcionar para a página da aplicação. Em domínio você encontra o link para sua aplicação. Você pode até abrir no celular - sua aplicação está no ar e funcionando!

Próximos passos

Agora que você já sabe como deployar uma aplicação na nuvem, deixo para você aproveitar o free tier para explorar diferentes integrações e serviços. A melhor forma de aprender é experimentando!

Quer ir além do front-end e trabalhar com back-end? Tenho outro artigo sobre como construir seu primeiro sistema serverless com AWS Lambda.

Se tiver dúvidas ou quiser compartilhar feedback, fique à vontade para me procurar!

SDK: as ferramentas para seu código se conectar com o mundo

Giovana Armani — Thu, 05 Mar 2026 21:58:25 +0000

Se você já tentou integrar sua aplicação com serviços externos como serviços de nuvem, aplicativos de localização, autenticação ou pagamento, provavelmente já usou um SDK sem nem perceber. Mas afinal, o que é um SDK e por que ele é importante para nós desenvolvedores?

O que é SDK?

SDK significa Software Development Kit (em português Kit de Desenvolvimento de Software). Gosto de pensar nele como uma caixa de ferramentas para construir aplicações sobre uma plataforma, sistema operacional ou linguagem de programação.

Um SDK geralmente inclui:

Bibliotecas de código prontas para usar
APIs para comunicação com serviços (leia mais sobre o que é uma API nesse link)
Documentação detalhada
Exemplos de código práticos
Ferramentas de desenvolvimento (debuggers, compiladores, etc.)

Por que SDKs existem?

SDKs existem para acelerar o desenvolvimento e reduzir a complexidade. Eles reunem toda a lógica complicada de integração, permitindo que você foque na funcionalidade da sua aplicação.

Vamos imaginar, por exemplo, que você está construindo um sistema de vendas e quer adicionar a possibilidade de pagamentos. Ao invés de programar essa funcionalidade do zero e ainda fazer as integrações com sua aplicação, você pode usar um SDK!

Usando em código, um o uso de um SDK de pagamentos, como o do Paypal, se pareceria com algo assim:

// Importar o SDK do PayPal
import paypal from '@paypal/checkout-server-sdk';

// Configurar o SDK com suas credenciais
const idCliente = '<seu-id-cliente>';
const segredoCliente = '<seu-segredo-cliente>';
const ambiente = new paypal.core.SandboxEnvironment(idCliente, segredoCliente);
const cliente = new paypal.core.PayPalHttpClient(ambiente);

// Criar um pedido de pagamento
async function criarPagamento() {
    const requisicao = new paypal.orders.OrdersCreateRequest();

    requisicao.requestBody({
        intent: 'CAPTURE',
        purchase_units: [{
            amount: {
                currency_code: 'USD',
                value: '29.99'
            },
            description: 'Assinatura Premium'
        }]
    });

    // O SDK cuida da requisição HTTP, autenticação e resposta
    const resposta = await cliente.execute(requisicao);

    console.log('Pagamento criado:', resposta.result.id);
    return resposta.result;
}

criarPagamento();

Sem um SDK, você precisaria manualmente lidar com requisições HTTP, gerenciar autenticação, tratar erros e muito mais. O SDK faz tudo isso por você!

Qual é a diferença entre SDK, API e Bibliotecas?

Começando com as definições, já vimos que um SDK é kit de desenvolvimento com várias ferramentas. Uma API é um contrato de comunicação entre programas que especifica como informações vão ser passadas entre eles. Por último, uma biblioteca é um conjunto de funções que podem ser reutilizadas por vários programas.

Passando para um exemplo do mundo real, imagine que o mundo dos códigos seja um restaurante. Bibliotecas são os livros de receita que ensinam a fazer pratos específicos. As APIs são o cardápio que mostram o que um cliente pode pedir e como. Já o SDK é a cozinha completa com várias ferramentas para preparar o que você quiser.

Na imagem acima, as bibliotecas estão dentro das APIs que estão dentro dos SDKs, mas lembre-se que elas podem existir independentemente tambem.

Resumindo:

	SDK	API	Biblioteca
O que é	Kit completo de ferramentas para desenvolvimento	Contrato de comunicação entre programas	Coleção de funções reutilizáveis
Propósito	Facilitar desenvolvimento para uma plataforma	Permitir integração entre sistemas	Resolver problemas específicos
Exemplos	SDK do Google para Android, Stripe SDK para pagamentos, SDK do Facebook, SDK do Arduino para IOT	REST API do Twitter, Web API do Spotify, API do Github, API da NASA	Pandas (manipulação de dados com python), Lodash (utilitários do javascript), Gson (manipulação de json em java), NLog (registros de log para C# e .NET)

Aspectos essenciais de um SDK

Ao escolher um SDK para usar no seu projeto, é importante considerar:

1. Licença

É open source ou proprietário? SDKs open source são livres para ser usados por todos (e você pode até colaborar com a construção deles!), já os proprietários, é possível que você precise de permissão para usar
Quais são as restrições de uso?
Há custos associados?

2. Documentação

A documentação é clara e completa?
Existem exemplos práticos?
Há guias de início rápido?

3. Compatibilidade

Funciona com a linguagem que você está usando?
É compatível com as versões que você tem dessa linguagem?
Suporta as plataformas que você precisa (web, mobile, server)?

4. Suporte

Há uma comunidade ativa?
O SDK é mantido regularmente?
Existe suporte oficial?

5. Segurança

Como as credenciais são gerenciadas?
Há atualizações de segurança regulares?

Próximos passos

Agora você já sabe o que é um SDK e como ele difere de APIs e bibliotecas! SDKs são ferramentas poderosas que economizam tempo e reduzem a complexidade ao integrar sua aplicação com plataformas externas.

No meu último artigo, usei o SDK da AWS para construir uma aplicação com função Lambda do zero (veja no artigo o passo a passo) e nem contei pra vocês! Na próxima semana, vamos explorar ainda mais o SDK da AWS para javascript!

Seu primeiro sistema serverless com AWS Lambda

Giovana Armani — Thu, 26 Feb 2026 22:29:58 +0000

A ideia de subir código na nuvem pode parecer muito complexa para quem nunca fez isso antes. E se chover? Ai ferrou minha aplicação...
Brincadeirinhas à parte, juro que é mais tranquilo do que parece. Nesse artigo vamos construir uma aplicação na nuvem do zero usando AWS Lambda!

O que é AWS Lambda?

AWS Lambda é um serviço da AWS que permite você criar sistemas serverless. Isso significa que você não precisa configurar os servidores do seu sistema, a nuvem faz isso pra você e você fica livre pra focar no código! Para saber mais sobre serverless e suas vantagens e desvantagens, veja esse artigo: A verdade oculta por trás do Serverless

Uma função Lambda é uma unidade de código que fica na nuvem esperando ser chamada para executar alguma tarefa. Chamamos de evento o acontecimento que aciona a função. Em sistemas gerais, esse evento pode ser uma notificação, uma atualização no banco de dados, um usuário apertando um botão, entre outros. Após ser acionada, uma função Lambda pode executar várias tarefas, inclusive chamar outros serviços como um banco de dados.

Por onde começar?

Tudo que veremos nesse post pode ser replicada em uma conta free tier da AWS! Ela permite que você comece a explorar vários serviços da AWS gratuitamente e apenas será cobrado caso escolha trocar de plano. Aprenda mais sobre o free tier e como setar sua conta nesse post.

Nossa aplicação de exemplo

Para demonstrar como subir e rodar código na nuvem, vamos construir uma aplicação que transforma arquivos CSV (ou planilhas de Excel) em JSON. Sei que existem sites que já fazem isso gratuitamente, mas às vezes precisamos converter arquivos privados e sensíveis que talvez a gente não queira subir em um sistema de outros. Em momentos como esse, é muito bom ser dev e conseguir construir sua própria solução rapidinho!

O diagrama abaixo demonstra o funcionamento do nosso programa. Vamos subir o arquivo que queremos converter em um bucket do Amazon S3 (Amazon Simple Storage Service). Ele é um serviço de armazenamento de arquivos oferecido pela AWS. A ação de colocar o arquivo no bucket vai acionar nossa função lambda. Ela vai buscar o arquivo no bucket, converter para JSON e colocar o arquivo convertido em outro bucket de output.

Construindo a aplicação

Listarei a seguir os passos que segui para construir a aplicação. Siga os passos para construir comigo ou acompanhe o processo pelo video no final.

Você sabia que pode configurar as páginas da conta AWS para ficar em português caso não esteja automaticamente? Assim que entrar na sua conta, selecione o ícone de engrenagem à direita da tela e no dropdown embaixo de "Language", selecione "Portugês"!

Criando a função inicial

Na conta free tier da AWS, naveguei até a página do Lambda através da caixa de busca
Cliquei em "Criar função"
Chamei minha função de csvToJsonConverter e selecionei nodejs24.x como linguagem. Outras configurações mantive como default
Cliquei em "Criar função" no canto inferior direito da página para criar e ser direcionada para a página da função
Na seção de Configurações de tempo de execução, me certifiquei que o manipulador era index.handler, para indicar o ponto de entrada da aplicação
Na página da função Lambda, na aba de código, existe um editor de texto, como demonstrado na imagem acima, que pode ser usado para escrever o código da função. Essa funcionalidade está disponível para códigos em Node.js, Python e Ruby. Nele, já existia um arquivo chamado index.mjs que serve como porta de entrada do programa. Em funções Lambda, essa porta de entrada é chamada de handler e no console da AWS em português é traduzido como "manipulador". Adicionei apenas um log no arquivo para validar minha estrutura inicial:

export const handler = async () => {
  console.log("Handler chamado!")

  const response = {
    statusCode: 200,
    body: JSON.stringify('Minha primeira função!'),
  };
  return response;
};

Parabéns! Você escreveu seu primeiro código na Lamba! Agora clique
no botão "Deploy" para subir o código para a função lambda!

Após criar essa estrutura inicial é possível testar a chamada para a função na aba de "Testar" e ver nos logs da execução se nosso código está sendo chamado como esperado. Para isso, mantive todas as configrações da aba de teste como estavam e apenas cliquei em "Testar".

Criando os buckets S3

Os buckets vão servir para armazenar nossos arquivos de entrada e de saída. Vamos criá-los!

Naveguei até a página do S3 pelo console da AWS
Cliquei em "Criar bucket" e chamei o bucket de gio-csv-converter-input e mantive outras configurações default (lembre-se de **sempre* bloquear todo o acesso público)*. Os nomes de buckets no S3 são únicos globalmente, então você não conseguirá usar o mesmo nome de bucket que o meu. Sugiro usar <seu-nome>-csv-converter-input
Cliquei em "Criar bucket" no final da tela de configurações para criar
Criei também outro bucket chamado gio-csv-converter-output que servirá para guardar os arquivos convertidos. Novamente, você precisará de um nome de bucket diferente. Sugiro <seu-nome>-csv-converter-output
Novamente, cliquei em "Criar bucket" no final da tela

Adicionando a conexão com o S3

Como vimos anteriormente, quando colocarmos um arquivo no bucket do S3, nossa função lambda vai ser acionada. Agora temos que avisar a AWS que vai ser assim

De volta na página da função lambda, cliquei em "Adicionar gatilho"
No dropdown de seleção procurei por "S3" e selecionei o serviço
Cliquei no campo de "bucket" e selecionei meu bucket de input
No campo de "Event types" selecionei "All object create events" que significa que será acionando smepre que um novo arquivo for adicionado no bucket
Mantive os campos de "Prefix" e "Sufix" vazios
Cliquei na caixa de seleção no campo de "Recursive invocation". Infelizmente a mensagem dela ainda não foi traduzida para o português, mas a tradução seria: Reconheço que usar o mesmo bucket S3 para entrada e saída não é recomendado e que essa configuração pode causar invocações recursivas, aumento no uso do Lambda e aumento nos custos. É por esse motivo que criamos buckets separados para o input e output. Se colocássemos o arquivo final do mesmo bucket de input, a lambda seria acionada novamente e entraríamos em um loop infinito (que eventualmente ia custar uma fortuna!)
Por fim, cliquei em "Adicionar" para criar o gatilho

Ao adicionarmos o S3 como gatilho para a função Lambda, a AWS vai automaticamente configurar as permissões para que o S3 possa acioná-la.

É possível ainda testar essa conexão pelo console navegando até o S3 e subindo um arquivo no bucket. Podemos ver os logs da nossa aplicação através do Amazon CloudWatch, o serviço de monitoramento de aplicações da AWS, seguindo os passos:

Usando a caixa de pesquisa do console da AWS, navegue para a página do CloudWatch
No menu à esquerda, clique em Logs > Gerenciamento de logs
Clique no nome da sua função Lambda que aparecerá na lista de Log groups
Procure pelo arquivo de log correspondente ao horário em que você executou a função

Implementação de funcionalidade e permissões

Usei a biblioteca @aws-sdk/client-s3 (clique aqui para a documentação) para conexão com os buckets S3 para acessar os arquivos. Escrevendo o código diretamente pelo console do Lambda, pude simplemente importar o que precisava sem instalar a biblioteca porque as funções Lambda já tem acesso ao SDK da AWS implicitamente. Para converter o conteúdo CSV para JSON, usei simples manipulação de string do javascript. Veja o código completo abaixo ou nesse repositório.

import { S3Client, GetObjectCommand, PutObjectCommand } from '@aws-sdk/client-s3';

const s3Client = new S3Client({});
const OUTPUT_BUCKET = 'gio-csv-converter-output';

export const handler = async (event) => {
    console.log('abacaxi');
    console.log(`event: ${JSON.stringify(event)}`);

    for (const record of event.Records) {
        const sourceBucket = record.s3.bucket.name;
        const sourceKey = record.s3.object.key;
        const destinationKey = sourceKey.replace('.csv', '.json');

        try {
        const csvContent = await getCSVFromS3(sourceBucket, sourceKey);

        const jsonData = csvToJson(csvContent);

        await uploadJsonToS3(destinationKey, jsonData);

        return {
            statusCode: 200,
            body: JSON.stringify({
                message: 'CSV converted to JSON successfully',
                source: `${sourceBucket}/${sourceKey}`,
                destination: `${OUTPUT_BUCKET}/${destinationKey}`,
            }),
        };
    } catch (error) {
        console.error('Error processing file:', error);
        return {
            statusCode: 500,
            body: JSON.stringify({ error: error.message }),
        };
    }
    }
};

async function getCSVFromS3(sourceBucket, sourceKey) {
    const getCommand = new GetObjectCommand({
            Bucket: sourceBucket,
            Key: sourceKey,
        });
    const response = await s3Client.send(getCommand);
    const csv = response.Body.transformToString();

    console.log(`String do csv puxado do S3: ${csv}`);
    return csv;
}

function csvToJson(csvContent) {
    const lines = csvContent.trim().split('\n');
    const headers = lines[0].split(',').map(h => h.trim());

    console.log(`Lines: ${lines}`);
    console.log(`Headers: ${headers}`);

    return lines.slice(1).map(line => {
        const values = line.split(',').map(v => v.trim());
        return headers.reduce((obj, header, index) => {
            obj[header] = values[index];
            return obj;
        }, {});
    });
}

async function uploadJsonToS3(destinationKey, content) {
    const putCommand = new PutObjectCommand({
        Bucket: OUTPUT_BUCKET,
        Key: destinationKey,
        Body: JSON.stringify(content, null, 2),
        ContentType: 'application/json',
    });
    await s3Client.send(putCommand);
}

Caso copie o código acima no editor de texto da função lambda para testar, não se esqueça de clicar em "Deploy"!

Uma coisa importante de configurar também são as permissões para a função Lambda conseguir acessar os buckets. Se quiser entender mais sobre como funciona o IAM e os diferentes tipos de permissão veja esse artigo, mas em linhas gerais, segui esses passos:

Na página da minha função Lambda, acessei a aba de "Configuração"
No menu esquerdo, selecionei "Permissões"
Cliquei no link embaixo de "Noma da função" que me direcionou para a página do IAM (AWS Identity and Access Management). Esse é o serviço que permite gerenciar permissões dentro da sua conta AWS
A página do IAM foi aberta diretamente na role da função Lambda que gerencia o que ela pode fazer em outros serviços. Cliquei em "Adicionar permissões" > "Criar política em linha"
Fui direcionada para a página do Policy Editor onde selecionei formato JSON e adicionei a permissão abaixo. Cliquei em "Próximo" no canto inferior da página e chamei a política de "AcessoAoS3" e cliquei em "Criar política" para terminar a criação

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetObjectPermission",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<nome-do-bucket-de-input>/*"
        },
        {
            "Sid": "PutObjectPermission",
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<nome-do-bucket-de-output>/*"
        }
    ]
}

Podemos ver que essa permissão contém dois objetos dentro do array de "Statement". Cada objeto desses concede um acesso diferente. O primeiro permite (sinalizado pelo "Effect": "Allow") que nossa função faça a ação de "GetObject" sobre o bucket de input. Ou seja, a função vai poder pegar os arquivos que colocarmos no bucket de input para fazer a conversão. Já o segundo, permite que a função faça a ação de "PutObject" no bucket de output, ou seja, coloque os arquivos convertidos no bucket para podermos baixar.

⚠️ Não se esqueça de trocar os nomes dos buckets na permissão acima pelo nome dos seus buckets!

Testando tudo junto!

Está pronto! Agora podemos testar a aplicação final!

Usei esse csv de exemplo e coloque ele no meu bucket de input do S3. É possível ver os logs da execução pelo CloudWatch como explicado anteriormente e ver o arquivo de output final do bucket de output!

Limpeza da casa

É uma boa prática nos acostumarmos a deletar os recursos da nuvem quando não estão mais em uso. Se algum dia você não estiver mais usando uma conta free tier, isso vai te poupar de ter cobranças surpresa (pode me agradecer depois). No nosso caso, os recursos criados foram uma função Lambda e dois buckets do S3.

Para remover a função, basta navegar até a página principal do serviço Lambda, selecionar a função que quer apagar e clicar em "Ações" > "Excluir".

Para remover os buckets, vá para para a página principal do S3, selecione o bucket e clique em "Excluir". É preciso que o bucket esteja vazio para que ele possa ser deletado. Caso não esteja, o console mostrará uma mensagem informando que é preciso esvaziá-lo. Você pode clicar em "Esvaziar bucket" para apagar todos os objetos. Após fazer isso, selecione o bucket novamente e clique em "Excluir".

Próximos passos

Agora você já sabe como subir seu código na nuvem e até mesmo como montar seu primeiro sistema serverless!

Uma limitação dessa aplicação que construimos é que os arquivos são convertidos para json um de cada vez, gerando vários documentos, mas e se quisermos colocar vários arquivos em um único output? Será que poderíamos subir uma pasta no S3 e converter tudo de uma vez?

Deixo como exercício clonar o repositório, replicar a infraestrutura que vimos e implementar essa funcionalidade nova!

A verdade oculta por trás do Serverless

Giovana Armani — Wed, 04 Feb 2026 20:20:10 +0000

Entenda de uma vez por todas o que realmente significa Serverless e porque isso fará toda a diferença no seu processo de desenvolvimento!

Primeiras definições

Antes de podermos falar do que é serverless, sabemos o que é um servidor?

Gosto de pensar servidores como aqueles computadores muito poderosos que parecem geladeiras (vai me dizer que não?). Existem vários tipos de servidores especializados em diferentes tarefas. Eles podem armazenar, processar, gerenciar e transferir dados e arquivos, executar programas, enviar emails, disponibilizar conteúdo na internet, entre muitas outras funções.

Evolução histórica

Nos primórdios da computação, cada empresa dona de um software, precisava comprar e manter seu próprio servidor para rodar sua aplicação. Isso adicionava uma alta carga de trabalho porque era preciso cuidar dessas máquinas, da mesma forma que cuidamos de nossos computadores pessoais, mas em escala muito maior. Tarefas como gerenciamento do sistema operacional, atualizações de segurança, gerenciamento do sistema de arquivos, balanceamento de carga, monitoramento e registro em log eram todas tarefas que deviam ser feitas regularmente para essas máquinas gigantes e complexas.

Além disso, o uso desses servidores não era nada eficiente. Imagine que a venda do seu Zé tinha um servidor para processar compras na sua loja virtual. Em momentos de pico de pedidos como Natal ou Black Friday, era preciso o poder de processamento do servidor inteiro. Já no resto do ano, o tráfego era bem mais baixo e em grande parte do tempo, só precisava de uma parte dele.

Isso adicionava um custo e um trabalho desnecessário porque apesar do seu Zé estar usando somente metade da sua "geladeira", ainda é preciso fazer manutenção dela inteira.

Por sorte, os provedores de computação em nuvem vieram solucionar esse problema com Serverless (ou na tradução pro português que quase ninguém usa, computação sem servidores). Nesse modelo, a empresa de nuvem é a dona dos servidores e ela permite que outras empresas e desenvolvedores utilizem suas máquinas sob demanda através da internet.

Como funciona a computação serverless

Eis a mentira: por mais que o nome tente te convencer que é possível rodar software sem servidores, ainda não estamos tão avançados. Com serverless, os computadores-geladeira ainda existem, mas são completamente administrados e mantidos pela empresa provedora de nuvem. Isso permite que a gente foque em resolver problemas com código e a nuvem cuida do resto.

Você pode imaginar como um serviço de lavanderia. Ao invés de comprar uma máquina de lavar, você leva suas roupas até a lavanderia, usa a máquina do tamanho que precisar, espera a roupa bater e depois paga apenas por aquela lavagem.

Na computação serverless, os programas são acionados pelo que chamamos de eventos. Um evento é um acontecimento que diz ao programa que é hora de fazer alguma tarefa, como a chegada de uma mensagem ou uma interação do usuário com a tela. No nosso exemplo da lavanderia, poderíamos considerar como evento o ato de colocar as roupas na máquina e apertar o botão de iniciar. Quando o evento for recebido, é iniciado o processamento que gera um resultado como uma escrita em banco de dados, uma geração de arquivos, uma chamada para outro serviço, etc.

Chamamos de funções serverless essas unidades de código que executam tarefas específicas acionadas pelos eventos.

Vantagens

Já deu pra entender que nesse modelo de computação, você não precisa administrar infraestrutura, mas vamos pensar quais são os verdadeiros benefícios disso.

1 Escalabilidade automática

Com o modelo serverless, não é mais necessário fazer vários cálculos de quanto recurso seu programa vai precisar para rodar. Em casos como o do seu Zé, em que o sistema sofre várias variações de volume de requisições, a nuvem vai detectar sua necessidade automaticamente e te oferecer uma parte maior ou menor, mais ou menos potente do servidor.

2 Redução de custo

Ao utilizar uma solução de computação serverless, você elimina o custo fixo de manter os servidores. Não é preciso pagar pelo espaço onde serão armazenados e nem a energia necessária para mantê-los rodando.

Além disso, com a escalabilidade automática, você paga exatamente pela parte do servidor utilizada pela sua aplicação. Acabou-se o tempo de pagar por um monte de máquinas sem trabalho!

3 Aumento de produtividade

Como a infraestrutura é inteiramente administrada pelo provedor de nuvem, nós devs não temos mais a responsabilidade de realizar tarefas de setup e manutenção como seleção do servidor, atualização de sistema operacional, estratégias de segurança, entre outros 🙌. Isso abre espaço pra se dedicar inteiramente no que fazemos de melhor: produzir código.

Computação serverless funciona para tudo?

Sim e não...

Sabemos que pra tudo se dá um jeitinho, principalmente se você for brasileiro. Na prática é possível adaptar a computação serverless para quase qualquer cenário, mas é importante reconhecermos que ela tem algumas limitações que pode fazer com que não atenda perfeitamente algumas situações.

1 Cold starts

Um dos principais desafios das funções serverless é o que chamamos de cold start (ou traduzido, "inicialização a frio"). Como nesse modelo os servidores são disponibilizados sob demanda para as aplicações, nas primeiras chamadas a uma função serverless após um período sem chamadas, a aplicação estará "fria".

No período de "aquecimento" da função, o provedor faz a preparação do ambiente para execução, inicializando o código. Isso impacta o que chamamos de latência da função, o período de demora desde a chamada até a resposta. As chamadas depois de um período inativo serão mais demoradas do que as demais, o que pode ser um problema em sistemas que precisam de respostas rápidas.

Se você quer saber mais sobre cold starts e como evitá-los pode conferir esse artigo (e me avise se gostaria de ver esse tipo de conteúdo em português 😉).

2 Limite de duração (Timeouts)

No geral, funções serverless não são projetadas para códigos que ficam rodando por muito tempo. É preciso definir o tempo de timeout dela, ou seja, o tempo máximo que poderá ser executada. Isso pode ser uma desvantagem em aplicações que exigem longa duração.

3 Custo em aplicações com cargas constantes e previsíveis

Custo é sempre uma preocupação quando construímos sistemas. Por oferecerem grande flexibilidade em tempo real, modelos de computação sem servidor costumam ter custos mais altos por transação quando comparado a transações em sistemas com servidor próprio. Contudo, o valor total acaba compensando quando avaliados em períodos maiores porque você só paga pelo que consome.

Cada sistema vai ter que ser analisado especificamente para decidir a melhor opção: servidor dedicado ou serverless, mas para sistemas com carga constante e previsível, é possível que um servidor dedicado apresente menor custo. Para ajudar nessa decisão, você pode usar o AWS Pricing Calculator para comparar os custos de diferentes abordagens.

Conclusão

Veja na tabela abaixo um compilado dos principais pontos de diferença que exploramos entre aplicações serverless e aquelas com servidor reservado.

	Servidor próprio	Serverless
Quem cuida do servidor	Dono da aplicação	Provedor de nuvem
Escalabilidade	Para escalar, é preciso comprar mais servidores ou servidores mais potentes	Escalabilidade automática administrada pela nuvem
Custo	Valor fixo de manutenção do servidor independente do uso	Pague somente pelo que a aplicação consumir
Tempo de resposta	Aproximadamente o mesmo em todas as chamadas	Primeiras chamadas após um período podem ter latência maior pelo cold start

A computação serverless revolucionou a forma que construímos sistemas. Ela nos empodera a construir sua aplicação de forma mais rápida e eficiente, sendo uma grande aliada na administração de infraestrutura de servidores.

E aí, você já conhecia computação serverless? Que tipo de aplicação você construiria dessa maneira?

Garanta o shape do verão com Kiro e Spec Driven Development

Giovana Armani — Fri, 09 Jan 2026 15:16:37 +0000

Como construi minha primeira aplicação com IA usando Kiro em poucos minutos e sem escrever código para acompanhar a frequência dos meus treinos.

Gosto muito de me exercitar e tenho muitos objetivos físicos. Meu grande problema é que quero fazer só os treinos que gosto e ignoro os que não gosto. Todo atleta passa por isso do seu jeito, mas para mim, isso significa treinar muita perna e não treinar braço nunca.

Sei que no fundo o que me falta é vergonha na cara, então pedi ajuda para o Kiro para construir uma aplicação onde eu posso registrar meus treinos para ter noção de quando estou fugindo demais. Nesse artigo, vim compartilhar como você pode usar o Kiro e Spec Driven Development para tirar suas ideias do papel de forma rápida e eficiente.

O que é o Kiro e Spec Driven Development?

O Kiro é um editor de código com poderes de IA que te ajuda no desenvolvimento de programas. Para isso, ele oferece duas formas de interação com a ferramenta: Vibe coding, na qual o programador pede auxílio para a IA sob demanda com prompts (instruções) específicos; e Spec Driven Development , onde você começa o programa descrevendo seus requisitos para a IA.

No modo de specs, o Kiro segue o seguinte fluxo:

Você guia o desenvolvimento e o Kiro te ajuda a agilizar. Você pode voltar as etapas e alterar arquivos anteriores a qualquer momento.

Na IDE você ainda verá algumas funcionalidades interessantes:

Specs: onde estarão concentrados seus arquivos de requisitos, designs e tarefas para as aplicações desenvolvidas com specs;
Agent Hooks: prompts pré definidos executados autonomamente no plano de fundo. É possível usar essa feature, por exemplo, para gerar documentação ou testes a cada vez que um arquivo é salvo, otimizar performance, etc;
Agent steering: regras que guiam o comportamento e respostas do agente através de arquivos que especificam padrões de design e código que ele deve seguir;
MCP Servers: lista todas as integrações com MCP configuradas para seu agente. Falaremos mais sobre eles em postagens futuras.

Saiba mais com a documentação desses conceitos e veja na imagem abaixo onde achar essas funcionalidades na IDE.

Definindo requisitos

Se o Kiro e Spec Driven Development nos ajudam a desenvolver rapidamente cuidando da parte mais densa de escrita de código, ele nos abre espaço para ser ainda mais atentos com nossos requisitos. O segredo de trabalhar efetivamente com IA é refinar nossas habilidades de comunicação para ter certeza que o que estamos imaginando para o sistema será traduzido para código corretamente. No processo de desenvolvimento de software é recomendado definir bem os requisitos funcionais e não funcionais da sua aplicação.

Requisitos funcionais ditam o que a aplicação deve fazer ou como os usuários devem poder interagir com ela. Eles se relacionam aos seus objetivos de uso da aplicação. Aqui devemos listar as funcionalidades, elementos de interface gráfica, outputs esperados, entre outros.

Já os requisitos não funcionais, vão para um lado mais técnico. Dizem respeito a expectativas de performance, qualidade e segurança do sistema, assim como administram limitações de recursos que podem impactar a aplicação. Podemos considerar, por exemplo, requisito de tempo de resposta para determinadas operações, que podem afetar decisões de arquitetura.

Padrão de requisitos EARS

EARS é o padrão de escrita de requisitos utilizado pelo Kiro. Significa Easy Approach to Requirements Syntax, ou abordagem simples para sintaxe de requisitos. Os requisitos no EARS são escritos em inglês em linguagem natural e seguem uma estrutura padrão sempre na mesma ordem:

While [optional pre-condition], when [optional trigger], the [system name] shall [system response].

Traduzido para o português, essa estrutura seria:

Enquanto [pré-condição opcional], quando [gatilho opcional], o [nome do sistema] deve [resposta do sistema].

Exemplo:

Enquanto o usuário estiver logado, quando o usuário clicar no botão de pagar, o site da loja do seu Zé deve ser redirecionado para a página de pagamento.

Para desenvolver com Kiro, você não precisa escrever seus requisitos assim, mas é importante entender esse padrão para conseguir fazer uma revisão cuidadosa do que ele produzir.

Primeiros passos com Kiro

Antes de mais nada, baixei e instalei o Kiro aqui: https://kiro.dev/downloads/

Em seguida, criei uma pasta local e abri na IDE do Kiro. No lado direito da IDE, selecionei Spec para começar a aplicação.

Você sabia que pode falar com o Kiro em português? Comecei a aplicação oferecendo o seguinte prompt com as especificações iniciais dos meus requisitos:

Por favor crie uma aplicação onde usuários possam registrar treinos feitos a cada dia. A aplicação deve conter uma UI que obedece os seguintes requisitos funcionais:

- Página principal: calendário que mostra todos os treinos realizados a cada dia. Deve ter um botão de registrar novo treino que leva para a página de registro

- Registro de treino: página com um formulário com um campo de data e uma lista com todos os tipos de treinos cadastrados. O usuário deve poder selecionar um ou mais treinos da lista ou adicionar um novo item na lista. Ao submeter o formulário, o usuário deve ser redirecionado para a página de calendário e conseguir ver os treinos que registrou

Ainda deve seguir o requisito não funcional abaixo:
- Armazenamento de dados local

Calma, eu não bati a cabeça para sair fazendo loucuras como um armazenamento de dados local. Essa foi uma decisão consciente porque quero manter a aplicação o mais simples possível por ora para focarmos no desenvolvimento de código com specs e ela será evoluída aos poucos enquanto abordamos outros assuntos. Disso podemos tirar uma reflexão importante de que os requisitos não têm sentido por si só, mas dentro de um contexto maior do sistema.

A partir desse prompt inicial, Kiro vai criar o documento de requisitos (requirements.md) na pasta .kiro/specs. Ele interpreta seus requisitos iniciais e adiciona detalhes a partir deles. Nessa aplicação, por exemplo, pedi que fosse adicionado um calendário e o Kiro adicionou o requisito de que o sistema permita a navegação entre meses e anos. Esse é um ótimo momento para revisar detalhes como a experiência de navegação e tratamento de erros.

Quando estava satisfeita, cliquei em "move to design phase" para prosseguir. Na sequência, Kiro criou o documento de design (design.md). Como parte dele, definiu a arquitetura, tecnologias e linguagens utilizadas, componentes e interfaces, modelos de dados e propriedades.

Finalmente, segui para o plano de implementação. Ele transformou o design em uma sequência de tarefas (tasks.md) que revisei e aprovei para execução. Algumas tarefas são ainda marcadas como opcionais e podemos pular para um desenvolvimento mais rápido e voltar para ela depois.

Veja o repositório com o código criado pelo Kiro e assista à demo abaixo:

Conclusão

Minha experiência com Kiro e Spec Driven Development foi surpreendentemente fluida e divertida!

Em poucas horas, consegui sair de uma ideia simples para uma aplicação funcional, sem me perder em detalhes técnicos ou ficar travada na implementação. Pude focar exatamente no resultado que eu queria e quando queria ajustar algo, foi fácil voltar às etapas anteriores e refinar.

Agora que tenho a base funcionando, posso evoluir a aplicação aos poucos - colocar um banco de dados decente e quem sabe uma funcionalidade de lembretes automáticos que me dê bronca por pular treinos... A melhor parte é que a estrutura criada pelo Kiro facilita todas as minhas ideias mirabolantes!

Quer experimentar você mesmo? Baixe o Kiro em kiro.dev e comece com um projeto simples que resolva algum problema seu. Pode ser um organizador de tarefas, um livro de receitas, ou qualquer coisa que você sempre quis construir mas nunca teve tempo. O importante é começar com requisitos claros e deixar o Kiro cuidar da parte técnica.

Comente aqui também suas ideias de evolução para minha aplicação e vamos todos ficar bem malhados juntos (ou fingir rs)!