Genômica Serverless na AWS Como o CSIRO Consulta Bilhões de Variantes por US$ 0,40/mês

Por que compartilhar dados genômicos é um problema de arquitetura cloud

Olha só o tamanho do desafio: biobancos com centenas de milhões de indivíduos, milhares de milhões de posições genômicas, e a necessidade de manter dados sensíveis sob controle dos custodiantes originais. Nada disso combina com um data lake centralizado. 🧬

O protocolo GA4GH Beacon foi criado exatamente pra isso: uma API federada pra descobrir dados genômicos e fenotípicos sem centralizá-los. Mas padrão sem implementação de referência é só papel.

O CSIRO, agência nacional de ciência da Austrália, construiu o sBeacon — uma implementação Beacon 100% serverless na AWS, pronta pra produção. Escala pra coortes de mega-biobanco, ingere arquivos VCF padrão sem transformação e responde consultas reais em ~1,5 segundo.

O custo? Cerca de US$ 0,40 por mês pra um dataset no nível do 1000 Genomes. Vamos entender como isso é possível. 🚀

A arquitetura: dois fluxos, zero servidores

O sBeacon se divide em dois processos limpos: onboarding de dados e consulta de dados. Tudo roda em Amazon S3, AWS Lambda, Amazon DynamoDB e Amazon Athena.

Onboarding — Indexe, não copie

O insight principal: os dados genômicos nunca saem do bucket S3 original. Só o metadata (status de doença, idade, localização) é indexado.

# Fluxo simplificado de onboarding (pseudo-código do sBeacon)
# 1. Usuário envia localização do dataset pro API Gateway
payload = {
    "vcfLocations": ["s3://bucket-custodiante/coorte.vcf.gz"],
    "metadataSource": "endpoint-ontoserver"
}

# 2. Lambda escreve metadata no S3 em formato ORC
write_orc(metadata, "s3://sbeacon-bucket/metadata/")

# 3. Índice de ontologia construído via Ontoserver (ou Ensembl OLS V4)
build_ontology_index(terms)

# 4. Athena CTAS monta tabelas de metadata consultáveis
athena.execute("""
    CREATE TABLE AS SELECT *
    FROM metadata_orc
    WHERE ...
""")

# 5. Arquivos VCF são referenciados, não copiados — índice tabix permite acesso aleatório

Como só o metadata é duplicado, o custo de ingestão é dominado por alguns megabytes de ORC, não por gigabytes de sequência.

Consulta — Fan-out com Lambda

Quando uma consulta chega, o API Gateway roteia pra uma Lambda Microservice. Ela resolve termos de ontologia no DynamoDB, consulta o Athena pro metadata e — se precisar de variantes — faz fan-out pelos VCFs:

# Módulo de Consulta de Variantes — padrão fan-out
def initiator_handler(event, context):
    # Fan-out do splitQuery pelos arquivos VCF
    for vcf in event["vcfLocations"]:
        invoke_lambda("splitQuery", {"vcf": vcf, "query": event["query"]})

    # Cada VCF gera performQuery por região genômica
    # performQuery usa bcftools + htslib com HTTP byte-range
    # Só ~1 KB é buscado por consulta — o VCF bruto nunca entra na memória da Lambda

A mágica está nas requisições HTTP byte-range do htslib: o performQuery passa a URL do S3 direto pro bcftools, que busca só a região indexada pelo tabix. Os bytes brutos da sequência nunca passam pela Lambda como dado retornável.

A matemática do custo (chr1, 2504 genomas)

O tempo de consulta fica plano conforme o número de variantes retornadas cresce — de 4 pra 400 variantes, a resposta fica em torno de 1,5 segundo.

Zero Trust, federado por design — e onde quebra

Modelo de segurança

O sBeacon aplica um modelo zero trust onde nenhum componente, usuário ou requisição é implicitamente confiável:

• Auth explícita: toda requisição carrega um JWT do Amazon Cognito, validado no API Gateway antes de qualquer Lambda rodar.
• RBAC via grupos Cognito mapeados pra níveis de divulgação:

• Compute efêmero: /tmp da Lambda é limpo entre cold starts, o subprocesso bcftools roda com timeout de 10s, nenhum estado persiste.
• Storage descentralizado: os vcfLocations de um dataset são URIs S3 que podem apontar pra buckets de outras organizações. Cada instituição faz deploy do seu próprio stack Terraform — sem infra compartilhada, sem data lake central.

⚠️ Limitações que você precisa planejar

1. Consultas de genoma inteiro dão timeout. O API Gateway tem timeout fixo. Se alguém tentar varrer o genoma todo por acidente, a requisição falha. Operações funcionais sobre o genoma completo exigem outra arquitetura (ex: Step Functions pra orquestração longa).

2. Concorrência da Lambda pode esgotar. Um único fan-out gera muitas invocações paralelas. Consultas em rajada podem "famintar" outras funções da mesma conta AWS. Monitore a métrica ConcurrentExecutions em nível de conta e de função.

3. Perda silenciosa por throttle. Invocações síncronas da Lambda não fazem retry automático em throttle. Um 429 do performQuery significa que o resultado é silenciosamente perdido a menos que você trate. Configure alarmes CloudWatch na métrica Throttles — ou use um error-catcher que envia email com diagnóstico em falha.

4. Cold starts após períodos ociosos. Fan-out em rajada após ociosidade adiciona latência. Provisioned concurrency ajuda, mas aumenta o custo idle.

Por que Lambda em vez de Step Functions?

O time escolheu Lambda explicitamente porque ele processa payloads muito maiores — crítico dado o tamanho e complexidade dos dados genômicos e o padrão fan-in/fan-out. Pra essa carga, Lambda foi mais barato e mais flexível.

O aprendizado: plataformas federadas de dados são um padrão resolvido

O sBeacon é um daqueles raros cases onde as escolhas de arquitetura são diretamente rastreáveis a números de custo e latência:

• Não copie o que você pode indexar. Referenciar VCFs no lugar de ingeri-los derrubou o storage pra centavos.
• Byte-range reads vencem data lakes. As requisições HTTP Range do htslib buscam ~1 KB por consulta — sem ETL, sem centralização.
• Fan-out serverless combina com genômica. Invocações paralelas de Lambda mapeiam naturalmente pro formato "escaneie muitos arquivos, retorne resultados pequenos".
• Zero trust não é buzzword aqui. Grupos Cognito, claims JWT e stacks Terraform por instituição aplicam isso estruturalmente.

Se você tá construindo genômica na AWS, pode fazer deploy do sBeacon sobre VCFs já hospedados no S3 e federar progressivamente com outros Beacons pra descoberta cross-institucional.

Próximos passos:

• Leia o paper do sBeacon ("Scalable genomic data exchange and analytics with sBeacon") pra metodologia dos benchmarks.
• Clone o repositório terraform-aws-serverless-beacon e rode um deploy local contra um VCF pequeno.
• Estude o padrão error-catcher pra surfar falhas de Lambda em arquiteturas fan-out.

Pra uma outra perspectiva sobre como falhas de capacity planning e observabilidade se desenrolam em pipelines de produção, veja nossa análise de um outage real de pipeline de mídia. E se você tá acompanhando como IA está remodelando plataformas de serviço, Gemini for Home mostra como IA proativa virou uma preocupação full-stack.

Fonte: AWS Architecture Blog — How CSIRO built scalable, cost-optimized genomic variant querying on AWS