Amazon SAA-C03: Transferência e Migração de Dados — Guia de estudos

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Faz parte do AWS SAA-C03 — Guia de estudos completo. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

A Decisão: Largura de Banda vs. Envio Físico

Toda migração começa com aritmética. Calcule o tempo de transferência teórico antes de escolher uma ferramenta:

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

Os números são implacáveis. Com 100 Mbps sustentados, 1 TB leva aproximadamente 24 horas; com 1 Gbps, cerca de 2,5 horas. Um link de 15 Mbps limitado a 70% de utilização entrega apenas ~113 GB por dia, então 20 TB precisariam de mais de 175 dias. Transferir 150 TB durante a noite (10 horas a 80% de 100 Mbps) resulta em ~360 GB por noite, ou 10,5 TB por mês — nem de perto o suficiente para um prazo de 30 dias. Mesmo totalmente saturado 24/7, 100 Mbps movem apenas ~1 TB/dia, então 150 TB precisam de no mínimo 150 dias. Em escala de petabytes, o cenário piora: um link de 500 Mbps com eficiência do mundo real entrega aproximadamente 5,4 TB/dia de throughput teórico, o que significa que 10 PB exigiriam mais de cinco anos de transferência contínua — mais tempo do que a maioria dos circuitos Direct Connect leva para ser provisionada.

Uma regra geral razoável:

A resposta errada mais comum em cenários de migração é escolher uma transferência via WAN que matematicamente não pode ser concluída dentro do prazo. A armadilha decorrente — “vamos simplesmente rodar toda noite pela WAN” — não é apenas mais lenta. Ela consome largura de banda de produção, arrisca transferências parciais ou corrompidas que exigem novos uploads e, normalmente, custa mais quando as cobranças de largura de banda e o tempo de engenharia são contabilizados. A cobrança por uma unidade Snowball mais o frete é um item de custo fixo e previsível.

A Família Snow para Transferência em Massa Offline

Os dispositivos Snowball Edge vêm em duas variantes:

O Snowcone é o formato pequeno (~8 TB SSD), robusto e enviável por transportadora, útil para locais com restrição de espaço e pré-carregado com agentes do DataSync para sincronização na borda. O Snowmobile — um contêiner de 45 pés que transporta até 100 PB — era voltado para evacuações de data centers em escala de exabytes, mas foi descontinuado em favor de frotas paralelas de Snowball Edge na maioria das regiões. Selecionar o Snowmobile para qualquer coisa abaixo de um petabyte é um distrator.

A variante Compute não é apenas um drive maior. Ela executa AMIs do EC2, funções Lambda e workloads do Greengrass localmente, tornando-a a escolha certa quando os dados precisam ser transformados, filtrados ou ter informações de identificação pessoal (PII) redigidas antes da ingestão, quando um workload precisa ser retomado imediatamente na AWS após a ingestão, ou quando o local está desconectado ou com conexão intermitente (navios, mineração remota, implantações táticas, pesquisa remota). Escolha a Compute Optimized quando o processamento no dispositivo é necessário; escolha a Storage Optimized quando o workload é pura cópia em massa.

Todo dispositivo Snow realiza criptografia de 256 bits em repouso usando chaves do KMS que nunca saem da AWS. Os gabinetes são à prova de violação, com uma etiqueta de envio E Ink e um Trusted Platform Module (TPM) de hardware. Os dados no dispositivo são gravados usando o cliente Snowball, o endpoint compatível com S3 ou uma montagem NFS; o TLS protege os dados em trânsito durante a ingestão e a troca do manifesto de envio. No retorno, o conteúdo é ingerido no S3 e o dispositivo é apagado criptograficamente de acordo com a norma NIST 800-88.

Para trabalhos de petabytes por local, o paralelismo é o padrão. Um escritório com capacidade de link de 1–2 Gbps ainda precisaria de meses de saturação contínua para mover 1 PB online; uma frota de ~13 dispositivos Storage Optimized por local (cada um com 80 TB) enviados em paralelo atinge um prazo de quatro semanas, poupando o link de internet do escritório. Para um trabalho de 600 TB em duas semanas em um link saturado de 100 Mbps, uma pequena frota em paralelo é a única resposta correta — mesmo ignorando o custo, a física torna o DataSync ou um novo Direct Connect impossíveis.

DataSync para Transferência Online, Verificada e Incremental

O DataSync é a ferramenta certa quando a largura de banda é suficiente, mas as características da carga de trabalho — milhões de arquivos pequenos, árvores de diretórios profundas, sincronizações incrementais contínuas ou migração entre sistemas de arquivos — comprometeriam o desempenho de ferramentas mais simples. Um diretório com 20 milhões de arquivos de 4 KB copiado com aws s3 cp é limitado pela latência de ida e volta, não pela vazão; cada PutObject incorre em uma viagem de ida e volta de TLS/HTTP e em uma cobrança de requisição de API. Agrupar em arquivos compactados funciona, mas sacrifica o endereçamento por arquivo. O agente do DataSync paraleliza o trabalho em muitos streams TCP, lida com metadados nativamente, verifica cada arquivo de ponta a ponta com checksum SHA-256, realiza novas tentativas de forma transparente e reporta para o CloudWatch — alcançando até ~10 Gbps por agente com um preço previsível por GB.

As origens e destinos abrangem NFS, SMB, HDFS, armazenamentos de objetos autogerenciados, S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS e FSx for NetApp ONTAP. As transferências usam TLS 1.2 em trânsito e podem atravessar endpoints de interface da VPC para não usar a internet pública.

Um detalhe crítico: o DataSync requer um agente para origens on-premises NFS/SMB. O agente é executado como uma VM no VMware, Hyper-V ou KVM, no EC2 ou no Snowcone. Acreditar que o DataSync não precisa de agente para ambientes on-premises é uma armadilha comum — ele só funciona sem agente quando ambos os endpoints são serviços nativos da AWS.

Uma implantação mínima:

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

Duas características operacionais são importantes. A limitação de largura de banda (BytesPerSecond) evita a saturação de um link compartilhado — respondendo diretamente a cenários como “link de 1 Gbps compartilhado com outros departamentos”. A filtragem e o agendamento permitem sincronizações fora do horário de pico e a exclusão de arquivos transitórios. Em um Direct Connect de 10 Gbps com usuários continuando a ler e escrever, agendar tarefas repetidas é o padrão canônico: a varredura inicial transfere a maior parte dos dados, execuções incrementais sucessivas capturam as diferenças (deltas), e 700 TB podem ser transferidos em bem menos de uma semana, mesmo com utilização parcial.

Uma armadilha mais sutil diz respeito à fidelidade dos metadados. O DataSync preserva um conjunto selecionado de atributos POSIX ou SMB — UID/GID/modo/timestamps para NFS, propriedade e DACLs para SMB — mas não captura todos os atributos proprietários de um NAS. ACLs específicas do fornecedor, atributos estendidos além do que o protocolo expõe, snapshots e metadados de desduplicação estão fora de seu escopo. Quando a conformidade exige uma réplica exata do NAS, incluindo recursos do fornecedor, o DataSync sozinho é insuficiente; é necessário um caminho que entenda a tecnologia NetApp, como o FSx for ONTAP com SnapMirror, ou um lift-and-shift via Storage Gateway.

O DataSync também complementa o Snowball: o Snowball move os 150 TB iniciais, e o DataSync lida com o delta semanal contínuo de um conjunto de trabalho (working set) de 500 GB posteriormente.

Storage Gateway: Apresentação Híbrida, Não Migração

O Storage Gateway não é uma ferramenta de migração — é uma camada de apresentação híbrida. As aplicações on-premises continuam a usar NFS, SMB, iSCSI ou iSCSI-VTL, enquanto os dados são armazenados em snapshots do S3, S3 Glacier ou EBS. Confundir o Storage Gateway com o DataSync é um erro frequente: o File Gateway não foi projetado para mover 70 TB rapidamente, e o DataSync não apresenta um compartilhamento persistente para clientes on-premises.

O File Gateway é o carro-chefe. Escrever em \\gateway\share\reports\2024\report.pdf produz s3://bucket/reports/2024/report.pdf — consumível nativamente pelo Athena, Lambda, EMR ou qualquer cliente S3. Esse mapeamento um-para-um de arquivo para objeto é uma grande vantagem sobre destinos de backup de caixa-preta (black-box). O cache local significa que arquivos quentes são retornados na velocidade da LAN; arquivos frios são transmitidos do S3 sob demanda.

O cache é o ponto principal do appliance. Leituras de dados quentes são servidas localmente; escritas são salvas primeiro no disco local e enviadas de forma assíncrona. Um erro de projeto comum é assumir que, por ter o S3 como backend, toda leitura incorre na latência de ida e volta da internet — isso não acontece, desde que o conjunto de trabalho (working set) caiba no cache. Por outro lado, subdimensionar o cache produz constantes erros de cache (cache misses) e a carga de trabalho parece “lenta”. Regra geral: cache = 20% do conjunto de dados total ou 100% do conjunto de trabalho quente, o que for maior.

A armadilha do modo Cached vs. Stored merece atenção especial. O modo Cached mantém a cópia primária no S3 com os blocos quentes locais — barato, elástico, mas um erro de cache (cache miss) significa uma viagem de ida e volta pela WAN. O modo Stored mantém a cópia primária no disco local com snapshots assíncronos para o S3 como snapshots do EBS — toda leitura é local e de baixa latência, mas o conjunto de dados inteiro deve caber no ambiente on-premises. Para um requisito de substituição de backup de “acesso local a todos os dados enquanto eles são copiados para a AWS”, o modo Stored é o correto; o modo Cached violaria o requisito. Escolher o modo Cached para uma carga de trabalho que precisa de todo o conjunto de dados com baixa latência invalida o projeto; escolher o modo Stored quando o local não pode hospedar o conjunto de dados completo é impossível por definição.

O Tape Gateway atende a um requisito muito específico: aposentar uma biblioteca de fitas física, mantendo intactos os fluxos de trabalho (workflows) do Veeam, NetBackup ou Commvault, apresentando uma VTL sobre iSCSI, com os dados passando por um ciclo de vida do S3 para o Glacier ou Deep Archive. É inestimável quando a retenção regulatória é definida em termos de mídias de fita e o software de backup existente não pode ser alterado.

AWS Transfer Family

O Transfer Family fornece endpoints totalmente gerenciados de SFTP, FTPS, FTP e AS2, com backend no S3 ou EFS. A proposta de valor é a preservação dos contratos de protocolo voltados para parceiros: sistemas de fornecedores que emitem arquivos apenas via SFTP continuam a fazê-lo sem alterações, enquanto a ponta receptora é o S3 nativo — com políticas de ciclo de vida, gatilhos Lambda e integração com analytics.

A armadilha aqui é presumir que um fornecedor legado pode “simplesmente mudar para as APIs do S3”. Muitos sistemas de fornecedores são appliances, feeds HL7 de hospitais, sistemas de lote bancários ou pipelines de EDI B2B cujo cliente SFTP está embutido no firmware ou em binários assinados. O custo de gerenciamento de mudanças, revisão de segurança e recertificação para alterá-los geralmente excede o custo de toda a migração para a AWS. O Transfer Family contorna isso completamente. O suporte a AS2 habilita adicionalmente cargas de trabalho de EDI com recibos MDN e assinatura/criptografia de mensagens para conformidade B2B.

A autenticação suporta usuários gerenciados pelo serviço, AWS Directory Service (Managed Microsoft AD ou AD Connector para AD on-premise) ou um provedor de identidade personalizado via API Gateway/Lambda — permitindo que as credenciais corporativas existentes permaneçam como a fonte da verdade. Um autorizador Lambda pode retornar IAM roles por usuário, mapeamentos de diretório home e políticas de sessão, proporcionando isolamento por fornecedor sem uma infraestrutura por fornecedor.

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

O AppFlow é a camada de integração gerenciada para movimentação de dados de SaaS para a AWS: Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk e dezenas de outros fluindo para o S3, Redshift ou Snowflake. Ele lida com paginação, extração incremental, mapeamento de campos, filtragem, mascaramento e validação sem a necessidade de um trabalho de ETL desenvolvido manualmente.

A característica crítica de segurança é a integração com o PrivateLink para conectores suportados (notavelmente o Salesforce). Em vez de sair para a internet pública para alcançar o tenant do SaaS e retornar para a AWS, o fluxo atravessa um endpoint de VPC privado — eliminando a exposição de cargas de extração na internet pública e simplificando a postura de auditoria para cargas de trabalho de saúde, finanças e PII. Os fluxos (flows) podem ser agendados, acionados por eventos de alteração de registros no SaaS ou executados sob demanda, e suportam até 100 GB por execução de fluxo.

O AppFlow opera em uma camada superior ao DataSync ou Storage Gateway: é a ferramenta certa quando a origem é um SaaS orientado por API, não um sistema de arquivos ou banco de dados.

Migração de Banco de Dados: DMS e SCT

O AWS Database Migration Service replica dados entre bancos de dados de origem e de destino enquanto a origem permanece totalmente operacional. Ele suporta migrações homogêneas (MySQL → RDS MySQL, Oracle → RDS Oracle) e heterogêneas (Oracle → Aurora PostgreSQL, SQL Server → MySQL), e os destinos se estendem além do RDS para Aurora, Redshift, S3, DynamoDB e Kinesis. As origens incluem Oracle, SQL Server, MySQL, PostgreSQL, MongoDB e Db2.

Uma tarefa (task) opera em um de três modos:

O motor por trás de uma virada (cutover) com tempo de inatividade mínimo é o Change Data Capture. Durante a carga completa com CDC, o DMS copia em massa as linhas existentes enquanto minera o log de transações da origem — redo do Oracle, binlog do MySQL, MS-CDC ou MS-Replication do SQL Server. Assim que a carga completa termina, o CDC aplica as alterações enfileiradas e mantém o destino continuamente atualizado até que a aplicação faça a virada. Não habilitar o CDC quando a aplicação precisa permanecer gravável é um erro de arquitetura comum: o modo de carga completa apenas deixa o destino desatualizado no momento em que a carga termina.

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

Para trabalhos heterogêneos, o AWS Schema Conversion Tool (ou seu irmão na nuvem, o DMS Schema Conversion) traduz DDL, stored procedures, views e funções, sinalizando itens que exigem reescrita manual. O DMS move os dados; o SCT converte o schema. Pular o relatório de avaliação do SCT é como as migrações falham três dias antes da virada.

Pré-requisitos e limitações específicos do motor de banco de dados podem causar grandes problemas se ignorados. LOBs do Oracle acima de 64 KB exigem o modo LOB limitado (limited LOB mode) com um máximo fixo; LONG RAW tem ressalvas. O PostgreSQL exige wal_level=logical e uma role de replicação. O MySQL exige log binário no formato ROW com binlog_row_image suficiente e privilégios elevados para CDC (REPLICATION CLIENT, REPLICATION SLAVE). Oracle Spatial, comportamentos específicos do RAC e assemblies CLR do SQL Server geralmente não são suportados. O TLS é imposto entre a instância de replicação e os endpoints, com os modos SSL require, verify-ca ou verify-full.

DMS Serverless é a escolha correta quando o perfil da carga de trabalho é imprevisível ou tem picos — um sistema Oracle on-premise com picos durante o dia e noites tranquilas, por exemplo. Você define MinCapacityUnits e MaxCapacityUnits em DCUs (DMS Capacity Units) e o DMS escala a capacidade de replicação com base na pressão de CPU e memória:

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

Uma armadilha frequente é presumir que uma instância provisionada do DMS (ex: dms.c5.4xlarge) irá escalar automaticamente. Ela não vai — instâncias provisionadas são hosts EC2 de tamanho fixo. Se a vazão (throughput) exceder a capacidade, o atraso na replicação (replication lag) aumenta e você deve modificar manualmente a classe da instância, reiniciando as tarefas. O DMS provisionado é adequado para migrações de estado estável com vazão conhecida; o Serverless é adequado para as imprevisíveis.

Para uma migração de 20 TB de MySQL com uma janela de duas semanas e tempo de inatividade restrito, a jogada de melhor custo-benefício é usar o DMS com carga completa mais CDC para o Aurora MySQL ou RDS MySQL. Restaurações nativas com mysqldump/mysqlpump incorrem em tempo de inatividade inaceitável; o Snowball adiciona latência de envio e lacunas offline.

O DMS Fleet Advisor descobre inventários de bancos de dados on-premise, o que é útil para o planejamento em ondas (wave planning).

Migração de Servidores: AWS Application Migration Service (MGN)

O AWS Application Migration Service é o principal serviço de lift-and-shift (“rehost”) e substituiu o CloudEndure Migration e o Server Migration Service para a maioria dos casos de uso. O MGN instala um AWS Replication Agent leve em cada servidor de origem (físico, VMware, Hyper-V ou de outra nuvem). O agente realiza um snapshot inicial em nível de bloco em uma área de staging de baixo custo na VPC de destino — pequenas instâncias T3 com volumes EBS anexados — e, em seguida, replica continuamente as alterações em nível de bloco de forma assíncrona. Como a replicação é em nível de bloco e contínua, o cutover é medido em minutos: o MGN converte os volumes de staging em instâncias EC2 de produção do tipo de instância de destino no momento do cutover.

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

Lançamentos de teste são essenciais e frequentemente ignorados. O MGN cria instâncias de teste isoladas a partir do estado de replicação atual, sem interromper a replicação em andamento. Você valida o comportamento da aplicação, descarta o teste, itera e só inicia o cutover quando os testes são aprovados — o cutover interrompe a replicação, lança a instância final e marca a wave como concluída.

A abordagem incorreta é exportar manualmente VMs para OVF, fazer o upload via aws ec2 import-image e reinstalar aplicações em instâncias EC2 recém-provisionadas. Isso é lento, propenso a erros, exige um tempo de inatividade por VM igual à duração da exportação, não fornece replicação delta e não oferece testes não disruptivos. O MGN elimina tudo isso — a origem continua em execução até o segundo final do cutover, e o desvio (drift) entre a origem e o destino é essencialmente zero.

A orientação geral do portfólio é fazer o rehost primeiro e, depois, fazer o re-platform ou refactor na Região, onde o custo de iteração é menor. Refatorar e migrar simultaneamente multiplica o risco sem um benefício que o compense.

Conectividade Híbrida: Direct Connect e VPN

O AWS Direct Connect fornece um circuito dedicado de Camada 2 de um roteador on-premises para um local do Direct Connect, oferecendo largura de banda consistente (1, 10, 100 Gbps dedicada; sub-1 Gbps via conexões hospedadas por parceiros) e latência previsível. As Virtual Interfaces (VIFs) particionam o circuito:

• Private VIF — acesso a uma única VPC por meio de um Virtual Private Gateway.
• Transit VIF — acesso a muitas VPCs por meio de um Direct Connect Gateway anexado a um Transit Gateway. Este é o padrão canônico para grandes ambientes com múltiplos VPCs e múltiplos sites.
• Public VIF — acesso a endpoints de serviços públicos da AWS (S3, DynamoDB) sem passar pela internet.

O DX não é, por si só, altamente disponível: um único circuito em um único local de DX depende de um único caminho de fibra. Dois padrões de resiliência são importantes:

1. DX + backup de VPN Site-to-Site pela internet é a alta disponibilidade mínima viável. O BGP lida com o failover automático com AS-path prepending, MED ou local-pref para preferir o DX em estado estável.
2. Circuitos DX duplos em locais de DX separados é o padrão de máxima resiliência para cargas de trabalho de missão crítica e é exigido para o SLA do DX.

Deixar de provisionar qualquer caminho de backup é uma armadilha bem conhecida: quando o DX falha e não há VPN, aplicações híbridas, jobs do DataSync e uploads do Storage Gateway param durante todo o tempo de reparo da operadora. Uma conexão puramente VPN é aceitável para cargas de trabalho de menor throughput ou como uma ponte enquanto o DX está sendo provisionado, o que pode levar semanas.

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

Onde a criptografia na camada física é obrigatória, escolha uma conexão DX habilitada para MACsec. Combinar DX para largura de banda, DataSync para orquestração e Storage Gateway para acesso local contínuo é o padrão híbrido canônico para grandes conjuntos de dados ativos que não toleram uma janela de inatividade.

AWS Outposts para Infraestrutura AWS On-Premises

O Outposts estende a infraestrutura da AWS para as instalações de um cliente como um rack totalmente gerenciado (ou servidores Outposts 1U/2U). Ele executa um conjunto selecionado de serviços localmente — EC2, EBS, ECS, EKS, RDS, S3 on Outposts, EMR — com as mesmas APIs da Região-pai. As operações do plano de controle fluem de volta para a Região-pai por meio de um link de serviço (service link) de túneis criptografados redundantes; uma interrupção da WAN impede temporariamente o lançamento de novas instâncias, mas não interrompe as cargas de trabalho em execução.

A divisão de responsabilidade compartilhada é a armadilha que pega os operadores. A AWS entrega e mantém o hardware, o hypervisor e os serviços gerenciados. O cliente é responsável por:

• Espaço físico, energia, refrigeração e rede que atendam às especificações do Outposts (fontes de alimentação redundantes, switches upstream, PDUs apropriados).
• Segurança física das instalações.
• Configuração da rede local — o Local Gateway (LGW) para o tráfego on-premises e o uplink do link de serviço.
• Questões de SO e aplicação das cargas de trabalho, exatamente como na Região.
• Conectividade WAN adequada de volta para a Região-pai.

O Outposts não elimina as operações — ele desloca a abstração. Assumir que a AWS é responsável pela energia do datacenter ou pela rede upstream é um erro fundamental de interpretação. Também não se trata de “executar qualquer serviço da AWS on-premises”: a lista de serviços suportados é finita, e serviços como Route 53 ou IAM permanecem baseados na Região.

Para uma modernização de Hadoop/Spark onde os dados devem permanecer on-premises por razões regulatórias, EMR on Outposts é o padrão correto — clusters Spark elásticos e gerenciados com as ferramentas da Região e residência de dados local. O Storage Gateway ou o DataSync falham no requisito de residência; o lift-and-shift para o EMR na Região falha em conformidade (compliance).

Distribuição de Conteúdo para Frotas de Edge

Quando servidores Outposts, lojas de varejo ou dispositivos de edge baixam repetidamente o mesmo payload grande — uma versão de software noturna, por exemplo — buscar diretamente de um bucket S3 em uma única Região satura os uplinks e aumenta o tempo de implantação. O padrão correto é CloudFront com uma origem S3 e URLs assinadas:

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

O primeiro dispositivo em uma região “aquece” o cache de edge; todos os dispositivos subsequentes baixam com a latência de edge. As URLs assinadas evitam downloads não autorizados sem a necessidade de credenciais IAM por dispositivo, e não há uma frota de réplicas regionais para gerenciar.

Dois antipadrões a serem rejeitados: hospedar a versão em um único servidor web EC2 (um desastre de escalabilidade e latência) e replicar o bucket S3 para todas as Regiões via Cross-Region Replication apenas para reduzir a latência de download (custo de armazenamento desnecessário e complexidade operacional que o cache do CloudFront resolve gratuitamente).

Resumo de Decisões

← Armazenamento e Ciclo de Vida de Dados · Todos os domínios · Redes e Conectividade →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →