O Que Mudou no DynamoDB Desde 2020

Fechar este lote de conceitos do DynamoDB com um pequeno adendo: o que a AWS de fato lançou para o DynamoDB desde 2020 que ainda não está coberto em outro lugar nesta categoria. Este conceito não tem fonte de livro alguma: The DynamoDB Book (2020) de Alex DeBrie antecede todo recurso abaixo, e tudo aqui é verificado diretamente contra a documentação atual da AWS e anúncios "What's New" da AWS, em vez de assumido a partir de conhecimento de treinamento, porque as datas exatas e nomes de recurso são recentes o suficiente para ser fácil errar. Um recurso intimamente relacionado está deliberadamente fora de escopo: o PartiQL, a linguagem de query compatível com SQL do DynamoDB, já é coberto completamente pelo conceito irmão dynamodb-using-the-api-well-expressions-and-avoiding-orms, que já linka sua própria referência PartiQL for DynamoDB; nada mais sobre isso aqui. Quatro coisas são genuinamente aditivas e novas: uma segunda classe de tabela, mais barata; uma forma no nível de recurso de conceder acesso; dois pipelines de dado sem código a partir do DynamoDB; e, mais recentemente, um modo de consistência forte opt-in para Global Tables que remove uma limitação que todo conceito de DynamoDB antes deste assumiu como certa.

• Armazenar anos de logs de aplicação, histórico de pedido substituído, ou conquistas antigas de jogo em uma tabela que é raramente lida, mas precisa continuar consultável: um candidato para a classe de tabela Standard-Infrequent Access (Standard-IA), em vez de Standard.
• Conceder a uma conta parceira acesso de leitura a uma tabela específica, ou um stream, sem escrever ou manter uma configuração separada de papel IAM entre contas: uma política baseada em recurso anexada diretamente àquela tabela ou stream.
• Rodar dashboards de BI ou analytics SQL ad hoc em dado DynamoDB ao vivo, sem construir manualmente um pipeline Streams-para-Lambda-para-Redshift: uma integração zero-ETL com o Amazon Redshift.
• Adicionar busca de texto completo ou vetorial em cima de itens DynamoDB (catálogos de produto, chamados de suporte, perfis de usuário) sem erguer e sincronizar um pipeline de ingestão OpenSearch separado você mesmo: uma integração zero-ETL com o Amazon OpenSearch Service.
• Construir um livro-razão financeiro multi-região, uma contagem de inventário, ou um armazenamento de perfil de usuário onde um leitor em uma região nunca deve ver dado obsoleto escrito em outra região: Multi-Region Strong Consistency (MRSC) para Global Tables, escolhido opt-in na criação da tabela.

Classe de tabela Standard-IA (dez. 2021)

Anunciada em 1º de dezembro de 2021, a classe de tabela DynamoDB Standard-Infrequent Access (Standard-IA) fica ao lado da classe original DynamoDB Standard como uma segunda opção, otimizada por custo. Segundo o próprio enquadramento da AWS, ela é "otimizada para tabelas onde armazenamento é o custo dominante. Por exemplo, tabelas que armazenam dado acessado com pouca frequência, como logs de aplicação, posts antigos de mídia social, histórico de pedido de e-commerce, e conquistas passadas de jogo, são boas candidatas para a classe de tabela Standard-IA." A troca é explícita e simétrica: Standard-IA oferece "custos de armazenamento 60 por cento menores do que as tabelas DynamoDB Standard existentes", mas o preço de requisições de leitura e escrita é mais alto do que Standard: a mesma forma do S3 Standard versus S3-IA, aplicada a um banco de dados, em vez de um armazenamento de objeto. Uma classe de tabela não é uma escolha permanente: "você pode mudar essa configuração usando o AWS Management Console, AWS CLI, ou AWS SDK", e todo índice secundário em uma tabela sempre compartilha a classe da tabela: não há como escolher Standard-IA para a tabela base, mas Standard para um GSI.

Políticas baseadas em recurso (mar. 2024)

Anunciadas em 20 de março de 2024, políticas baseadas em recurso permitem anexar uma política de acesso JSON diretamente a uma tabela DynamoDB, seus índices, ou um stream, em vez de expressar todo acesso exclusivamente através de políticas baseadas em identidade IAM anexadas a usuários ou papéis. A própria descrição da AWS: "políticas baseadas em recurso permitem definir permissões de acesso especificando quem tem acesso a cada recurso, e as ações que têm permissão para realizar em cada recurso... a política anexada a uma tabela vai conter permissões para acesso à tabela e seus índices." O caso de uso principal é compartilhamento entre contas: "um benefício significativo de usar políticas baseadas em recurso é simplificar controle de acesso entre contas, para fornecer acesso entre contas a principais IAM em contas AWS diferentes": não mais configuração de assunção de papel por conta só para deixar uma conta parceira ler uma tabela. Uma política tem teto de 20 KB, e o recurso vem com duas redes de segurança embutidas no fluxo de trabalho do console: o analisador de acesso externo do IAM Access Analyzer reporta qualquer acesso entre contas que uma política baseada em recurso concede, e Block Public Access (BPA) é "automaticamente habilitado nos fluxos de trabalho de criação e modificação de políticas baseadas em recurso", para impedir que uma política mal configurada acidentalmente exponha uma tabela publicamente. O recurso está disponível em todas as regiões comerciais da AWS sem custo adicional.

Integrações zero-ETL com Redshift e OpenSearch (2023-2024)

O DynamoDB agora vem com dois pipelines de dado gerenciados, sem código, a partir de uma tabela, ambos sob o nome "zero-ETL" que a AWS usa em vários serviços:

• Redshift. Anunciada em preview em novembro de 2023 e de disponibilidade geral a partir de 15 de outubro de 2024: "a integração zero-ETL do Amazon DynamoDB com o Amazon Redshift agora está geralmente disponível, permitindo que clientes rodem analytics de alta performance em seu dado DynamoDB no Amazon Redshift sem impacto nas cargas de trabalho de produção rodando no DynamoDB." Mecanicamente, "conforme dado é escrito em uma tabela DynamoDB, ele é tornado disponível de forma transparente no Amazon Redshift, eliminando a necessidade de clientes construírem e manterem pipelines de dado complexos para realizar operações de extração, transformação, e carga (ETL)." Ela mira em um workgroup Redshift Serverless ou um cluster provisionado em instâncias RA3, configurado pelo console, CLI, ou APIs do Redshift.
• OpenSearch Service. Anunciada em 28 de novembro de 2023, essa integração "fornece a clientes capacidades de busca avançadas, como busca de texto completo e vetorial, no seu dado Amazon DynamoDB", configurada "com alguns cliques de botão no console da AWS": o serviço "automaticamente entende o formato do dado nas tabelas Amazon DynamoDB e mapeia o dado para seus templates de mapeamento de índice." Também suporta reunir múltiplas tabelas de origem em um destino: "consolide dado de múltiplas tabelas Amazon DynamoDB em um cluster gerenciado ou coleção serverless Amazon OpenSearch único, para oferecer insights holísticos."

Ambas as integrações substituem o que costumava ser um pipeline DynamoDB Streams-mais-Lambda (ou Kinesis) feito à mão (veja o conceito irmão dynamodb-advanced-concepts-streams-ttl-partitions-consistency para como o próprio Streams funciona) por uma sincronização gerenciada, declarativa, que a AWS opera de ponta a ponta.

Multi-Region Strong Consistency para Global Tables (GA junho 2025)

O modelo de consistência original das Global Tables (o que todo outro conceito nesta categoria que menciona replicação assume) é consistência eventual multi-região (MREC): a réplica de cada região aceita escritas locais e as propaga assincronamente, então um leitor na Região B pode brevemente ver dado obsoleto em relação a uma escrita muito recente na Região A. Prevista em 3 de dezembro de 2024 e de disponibilidade geral a partir de 30 de junho de 2025, Multi-Region Strong Consistency (MRSC) é um segundo modo de consistência, opt-in, para Global Tables que fecha essa lacuna: mira em aplicações precisando de "um recovery point objective (RPO) de zero", e a documentação atual da AWS descreve Global Tables como suportando exatamente "dois modos de consistência: consistência eventual multi-região (MREC) e consistência forte multi-região (MRSC)."

Três restrições mecânicas importam mais do que o enquadramento de marketing:

• É uma escolha no momento da criação, não um toggle. "Se você não especificar um modo de consistência ao criar uma global table, a global table tem padrão de consistência eventual multi-região (MREC)... você não pode mudar o modo de consistência de uma global table depois da criação." Escolher MRSC, ou não, precisa acontecer no momento do design.
• Só mesma conta. "Global tables configuradas para MRSC só suportam configurações de mesma conta": o modelo mais novo de Global Tables multi-conta (fronteiras separadas de IAM/KMS/faturamento por conta) não é compatível com MRSC.
• Nenhuma mudança de aplicação exigida, mas limitado por região na GA. "Global tables usam as APIs existentes do DynamoDB para ler e escrever dado nas suas tabelas, então nenhuma mudança de aplicação é exigida", e faturamento segue "a precificação atual de global tables", sem nenhum item de linha separado destacado. Na GA, MRSC está disponível em dez regiões: US East (N. Virginia), US East (Ohio), US West (Oregon), Europa (Irlanda, Londres, Paris, Frankfurt), e Ásia Pacífico (Tóquio, Seul, Osaka): mais estreito do que o conjunto completo de regiões onde a própria Global Tables, ou MREC, roda.

• Standard-IA só vence se armazenamento genuinamente dominar. Preços mais altos por requisição significam que uma tabela com uma contagem pequena de item, mas tráfego constante de leitura/escrita, pode acabar mais cara em Standard-IA do que Standard: o desconto de 60% em armazenamento só se paga quando custo de armazenamento, não throughput, é o item de linha que você está tentando encolher.
• Políticas baseadas em recurso adicionam um segundo lugar onde autorização pode viver. Uma vez que uma tabela tem tanto uma política baseada em identidade no papel de quem chama quanto uma política baseada em recurso na própria tabela, conceder ou depurar acesso significa raciocinar sobre a combinação de ambas: a mesma categoria de complexidade que políticas de bucket do S3 introduziram anos antes, agora disponível no DynamoDB também.
• Zero-ETL é uma forma fixa de pipeline, não uma ferramenta de replicação genérica. Move dado exatamente para o Redshift ou exatamente para o OpenSearch, na agenda e lógica de inferência de schema da AWS: uma carga de trabalho precisando de um destino diferente, transformação customizada, ou controle de latência mais apertado ainda precisa de um pipeline baseado em Streams feito à mão, não de uma caixa de seleção.
• A lista de regiões e a restrição de mesma conta do MRSC são bloqueadores reais de adoção hoje. Uma aplicação distribuída globalmente que já abrange regiões fora das dez suportadas na GA, ou que já usa o modelo multi-conta de Global Tables por razões de governança, não consegue adotar MRSC sem reestruturar: e como o modo de consistência é travado na criação da tabela, retroaplicá-lo em uma global table MREC existente significa erguer uma tabela nova, não virar uma configuração.
• Todos os quatro recursos são recentes o suficiente para verificar antes de depender deles. Dois atingiram GA nos últimos dois anos (políticas baseadas em recurso, zero-ETL do Redshift) e um nos últimos dois meses no momento em que este texto foi escrito (MRSC): exatamente o tipo de detalhe (listas exatas de região, precificação, restrições de mesma conta) que muda mais rápido e vale a pena reverificar contra a documentação ao vivo da AWS, em vez deste conceito, antes de lançar em produção.