Este site utiliza cookies

Utilizamos cookies para melhorar sua experiência de navegação, personalizar conteúdo e analisar nosso tráfego. Ao clicar em 'Aceitar', você concorda com o uso de cookies conforme nossa Política de Privacidade.

VirtuAllIT Solutions
Proteção de Dados

Anunciando suporte à replicação e ao Intelligent-Tiering para tabelas do Amazon S3

AWS News Blog Team
04 de dezembro de 2025
8 min de leitura
Compartilhar:
Anunciando suporte à replicação e ao Intelligent-Tiering para tabelas do Amazon S3

Anunciando Suporte à Replicação e Intelligent-Tiering para Amazon S3 Tables

Hoje, anunciamos duas novas funcionalidades para o Amazon S3 Tables: suporte à nova classe de armazenamento Intelligent-Tiering, que otimiza automaticamente os custos com base nos padrões de acesso, e suporte à replicação, para manter automaticamente réplicas consistentes de tabelas Apache Iceberg entre AWS Regions e contas, sem a necessidade de sincronização manual.

Organizações que trabalham com dados tabulares enfrentam dois desafios comuns. Primeiro, elas precisam gerenciar manualmente os custos de armazenamento à medida que seus conjuntos de dados crescem e os padrões de acesso mudam ao longo do tempo. Segundo, ao manter réplicas de tabelas Iceberg em diferentes Regiões ou contas, elas precisam construir e manter arquiteturas complexas para rastrear atualizações, gerenciar a replicação de objetos e lidar com transformações de metadados.

Classe de Armazenamento Intelligent-Tiering do S3 Tables

Com a classe de armazenamento Intelligent-Tiering do S3 Tables, os dados são automaticamente escalonados para a camada (tier) de acesso mais econômica, com base nos padrões de acesso. Os dados são armazenados em três camadas de baixa latência: Acesso Frequente (Frequent Access), Acesso Infrequente (Infrequent Access) (40% mais barato que o Acesso Frequente) e Acesso Instantâneo de Arquivo (Archive Instant Access) (68% mais barato em comparação com o Acesso Infrequente).

Após 30 dias sem acesso, os dados são movidos para o Acesso Infrequente, e após 90 dias, são movidos para o Acesso Instantâneo de Arquivo. Isso acontece sem alterações em suas aplicações ou impacto no desempenho.

As atividades de manutenção da tabela, incluindo compactação (compaction), expiração de snapshot e remoção de arquivos não referenciados, operam sem afetar as camadas de acesso dos dados. A compactação processa automaticamente apenas os dados na camada de Acesso Frequente, otimizando o desempenho para dados ativamente consultados, enquanto reduz os custos de manutenção ao ignorar arquivos menos acessados (colder files) em camadas de custo mais baixo.

Por padrão, todas as tabelas existentes usam a classe de armazenamento Standard. Ao criar novas tabelas, você pode especificar Intelligent-Tiering como a classe de armazenamento, ou pode confiar na classe de armazenamento padrão configurada no nível do table bucket. Você pode definir o Intelligent-Tiering como a classe de armazenamento padrão para o seu table bucket para armazenar automaticamente as tabelas no Intelligent-Tiering quando nenhuma classe de armazenamento for especificada durante a criação.

Vejamos como funciona:

Você pode usar a AWS Command Line Interface (AWS CLI) e os comandos put-table-bucket-storage-class e get-table-bucket-storage-class para alterar ou verificar a camada de armazenamento (storage tier) do seu S3 table bucket.

bash
# Altera a classe de armazenamento
aws s3tables put-table-bucket-storage-class \
--table-bucket-arn $TABLE_BUCKET_ARN \
--storage-class-configuration storageClass=INTELLIGENT_TIERING

# Verifica a classe de armazenamento
aws s3tables get-table-bucket-storage-class \
--table-bucket-arn $TABLE_BUCKET_ARN \
{
"storageClassConfiguration": {
"storageClass": "INTELLIGENT_TIERING"
}
}

Suporte à Replicação do S3 Tables

O novo suporte à replicação do S3 Tables ajuda você a manter réplicas de leitura consistentes de suas tabelas entre AWS Regions e contas. Você especifica o table bucket de destino e o serviço cria tabelas de réplica somente leitura. Ele replica todas as atualizações cronologicamente, preservando as relações de snapshot pai-filho.

A replicação de tabelas ajuda você a construir conjuntos de dados globais para minimizar a latência de consultas para equipes distribuídas geograficamente, atender a requisitos de conformidade (compliance) e fornecer proteção de dados. Agora você pode criar facilmente tabelas de réplica que oferecem um desempenho de consulta semelhante ao das tabelas de origem.

As tabelas de réplica são atualizadas minutos após as atualizações da tabela de origem e suportam políticas independentes de criptografia e retenção em relação às suas tabelas de origem. As tabelas de réplica podem ser consultadas usando o Amazon SageMaker Unified Studio ou qualquer engine compatível com Iceberg, incluindo DuckDB, PyIceberg, Apache Spark e Trino.

Você pode criar e manter réplicas de suas tabelas por meio do AWS Management Console ou APIs e AWS SDKs. Você especifica um ou mais table buckets de destino para replicar suas tabelas de origem. Ao ativar a replicação, o S3 Tables cria automaticamente tabelas de réplica somente leitura em seus table buckets de destino, preenche-as com o estado mais recente da tabela de origem e monitora continuamente novas atualizações para manter as réplicas sincronizadas. Isso ajuda você a atender aos requisitos de viagem no tempo (time-travel) e auditoria, mantendo várias réplicas dos seus dados.

Vejamos como funciona:

Para demonstrar como funciona, farei em três etapas. Primeiro, crio um S3 table bucket, crio uma tabela Iceberg e a preencho com dados. Segundo, configuro a replicação. Terceiro, conecto-me à tabela replicada e consulto os dados para mostrar que as alterações são replicadas.

Para esta demonstração, a equipe do S3 gentilmente me deu acesso a um cluster Amazon EMR já provisionado. Você pode seguir a documentação do Amazon EMR para criar seu próprio cluster. Eles também criaram dois S3 table buckets, um de origem e um de destino para a replicação. Novamente, a documentação do S3 Tables o ajudará a começar. Anoto os Amazon Resource Names (ARNs) dos dois S3 Tables bucket. Nesta demonstração, refiro-me a eles como as variáveis de ambiente SOURCE_TABLE_ARN e DEST_TABLE_ARN.

Primeira etapa: Preparar o banco de dados de origem

Inicio um terminal, conecto-me ao cluster EMR, inicio uma sessão Spark, crio uma tabela e insiro uma linha de dados. Os comandos que uso nesta demonstração estão documentados em Accessing tables using the Amazon S3 Tables Iceberg REST endpoint.

bash
sudo spark-shell \
--packages "org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.4.1,software.amazon.awssdk:bundle:2.20.160,software.amazon.awssdk:url-connection-client:2.20.160" \
--master "local[*]" \
--conf "spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions" \
--conf "spark.sql.defaultCatalog=spark_catalog" \
--conf "spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkCatalog" \
--conf "spark.sql.catalog.spark_catalog.type=rest" \
--conf "spark.sql.catalog.spark_catalog.uri=https://s3tables.us-east-1.amazonaws.com/iceberg" \
--conf "spark.sql.catalog.spark_catalog.warehouse=arn:aws:s3tables:us-east-1:012345678901:bucket/aws-news-blog-test" \
--conf "spark.sql.catalog.spark_catalog.rest.sigv4-enabled=true" \
--conf "spark.sql.catalog.spark_catalog.rest.signing-name=s3tables" \
--conf "spark.sql.catalog.spark_catalog.rest.signing-region=us-east-1" \
--conf "spark.sql.catalog.spark_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO" \
--conf "spark.hadoop.fs.s3a.aws.credentials.provider=org.apache.hadoop.fs.s3a.SimpleAWSCredentialProvider" \
--conf "spark.sql.catalog.spark_catalog.rest-metrics-reporting-enabled=false"

spark.sql("""
CREATE TABLE s3tablesbucket.test.aws_news_blog (
customer_id STRING,
address STRING
)
USING iceberg
""")

spark.sql("INSERT INTO s3tablesbucket.test.aws_news_blog VALUES ('cust1', 'val1')")
spark.sql("SELECT * FROM s3tablesbucket.test.aws_news_blog LIMIT 10").show()

+-----------+-------+
|customer_id|address|
+-----------+-------+
|      cust1|   val1|
+-----------+-------+

Até agora, tudo bem.

#### Segunda etapa: Configurar a replicação para S3 Tables

Agora, uso o CLI no meu laptop para configurar a replicação do *S3 table bucket*. Antes de fazer isso, crio uma política AWS Identity and Access Management (IAM) para autorizar o serviço de replicação a acessar meu *S3 table bucket* e chaves de criptografia. Consulte a documentação de replicação do S3 Tables para obter os detalhes. As permissões que usei para esta demonstração são:

```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*",
"s3tables:*",
"kms:DescribeKey",
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}
]
}
```*

Após criar esta política IAM, posso prosseguir e configurar a replicação:

bash
aws s3tables-replication put-table-replication \
--table-arn ${SOURCE_TABLE_ARN} \
--configuration '{
"role": "arn:aws:iam::<MY_ACCOUNT_NUMBER>:role/S3TableReplicationManualTestingRole",
"rules":[
{
"destinations": [
{
"destinationTableBucketARN": "${DST_TABLE_ARN}"
}]
}
]

A replicação começa automaticamente. As atualizações são tipicamente replicadas em minutos. O tempo que leva para ser concluída depende do volume de dados na tabela de origem.

Terceira etapa: Conectar-se à tabela replicada e consultar os dados

Agora, conecto-me ao cluster EMR novamente e inicio uma segunda sessão Spark. Desta vez, uso o table bucket de destino. Para verificar se a replicação funciona, insiro uma segunda linha de dados na tabela de origem.

sql
spark.sql("INSERT INTO s3tablesbucket.test.aws_news_blog VALUES ('cust2', 'val2')")

Espero alguns minutos para que a replicação seja acionada. Acompanho o status da replicação com o comando get-table-replication-status.

bash
aws s3tables-replication get-table-replication-status \
--table-arn ${SOURCE_TABLE_ARN} \
{
"sourceTableArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test/table/e0fce724-b758-4ee6-85f7-ca8bce556b41",
"destinations": [
{
"replicationStatus": "pending",
"destinationTableBucketArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test-dst",
"destinationTableArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test-dst/table/5e3fb799-10dc-470d-a380-1a16d6716db0",
"lastSuccessfulReplicatedUpdate": {
"metadataLocation": "s3://e0fce724-b758-4ee6-8-i9tkzok34kum8fy6jpex5jn68cwf4use1b-s3alias/e0fce724-b758-4ee6-85f7-ca8bce556b41/metadata/00001-40a15eb3-d72d-43fe-a1cf-84b4b3934e4c.metadata.json",
"timestamp": "2025-11-14T12:58:18.140281+00:00"
}
}
]
}

Quando o status de replicação (replication status) mostra ready (pronto), conecto-me ao cluster EMR e consulto a tabela de destino. Sem surpresa, vejo a nova linha de dados.

Informações Adicionais

Aqui estão alguns pontos adicionais a serem observados:

  • A Replicação para S3 Tables suporta os formatos de tabela Apache Iceberg V2 e V3, oferecendo flexibilidade na escolha do formato da sua tabela.
  • Você pode configurar a replicação no nível do table bucket, tornando simples replicar todas as tabelas sob aquele bucket sem configurações individuais por tabela.
  • Suas tabelas de réplica mantêm a classe de armazenamento que você escolhe para suas tabelas de destino, o que significa que você pode otimizar para suas necessidades específicas de custo e desempenho.
  • Qualquer catálogo compatível com Iceberg pode consultar diretamente suas tabelas de réplica sem coordenação adicional — eles só precisam apontar para a localização da tabela de réplica. Isso oferece flexibilidade na escolha de query engines (mecanismos de consulta) e ferramentas.

Preços e Disponibilidade

Você pode rastrear seu uso de armazenamento (storage) por camada de acesso (access tier) por meio do AWS Cost and Usage Reports e das métricas do Amazon CloudWatch. Para monitoramento de replicação, os logs do AWS CloudTrail fornecem eventos para cada objeto replicado.

Não há cobranças adicionais para configurar o Intelligent-Tiering. Você paga apenas pelos custos de armazenamento em cada camada. Suas tabelas continuam a funcionar como antes, com otimização automática de custos baseada em seus padrões de acesso.

Para a replicação do S3 Tables, você paga as cobranças do S3 Tables pelo armazenamento na tabela de destino, pelas requisições PUT de replicação, pelas atualizações de tabela (commits) e pelo monitoramento de objetos nos dados replicados. Para a replicação de tabelas entre Regiões (cross-Region), você também paga pela transferência de dados inter-Região de saída (out) do Amazon S3 para a Região de destino, com base no par de Regiões. Como de costume, consulte a página de preços do Amazon S3 para obter detalhes.

Ambas as funcionalidades estão disponíveis hoje em todas as AWS Regions onde o S3 Tables é suportado. Para saber mais sobre essas novas funcionalidades, visite a documentação do Amazon S3 Tables ou experimente-as no console do Amazon S3 hoje mesmo. Compartilhe seu feedback através do AWS re:Post para Amazon S3 ou por meio de seus contatos de Suporte AWS.

— seb

Precisa de ajuda com suas soluções de TI?

A VirtuAllIT Solutions oferece consultoria especializada em virtualização, cloud computing e infraestrutura tecnológica.