Resumo

  • A AWS afirma que sua nuvem soberana europeia foi projetada para operar mesmo com a conectividade ao restante do mundo interrompida.
  • Essa continuidade da infraestrutura não garante a do workload. A partição aws-eusc requer contas e identidades próprias, e os mecanismos usuais de replicação S3 e peering inter-regional do Transit Gateway não atravessam a fronteira.
  • Um comprador só possui uma opção de recuperação quando o ambiente-alvo já está provisionado, sincronizado, autorizado, dimensionado e exercitado contra seu RTO e RPO.

A primeira ação para na fronteira

O operador aponta para aws-eusc um runbook escrito para duas regiões comerciais. A primeira sequência seria assumir um papel no alvo, conferir a réplica S3 e conectar a rede de recuperação. Segundo a AWS, nenhuma dessas continuidades deve ser presumida: as credenciais não atravessam a partição, nem S3 Cross-Region Replication, nem o peering inter-regional do Transit Gateway.

Antes de iniciar o aplicativo, o cliente já precisa de conta e identidade próprias, um método explícito para sincronizar ou restaurar dados e outro caminho de rede. É nesse ponto que a afirmação de independência do provedor precisa ser separada da recuperação do workload.

A proposta da AWS European Sovereign Cloud inclui uma afirmação forte: segundo a AWS, a primeira região soberana, em Brandemburgo, foi concebida para continuar operando se a conectividade com o restante do mundo for interrompida. A empresa diz que a infraestrutura é física e logicamente separada, permanece na UE e usa componentes dedicados de identidade, cobrança, confiança e DNS.

Essa afirmação descreve a independência operacional do provedor. Ela responde se a plataforma soberana pode continuar existindo sob isolamento. Não responde se um órgão público ou empresa regulada consegue acessar a plataforma, localizar dados suficientemente recentes, iniciar todas as dependências e atender usuários dentro do prazo prometido.

O contraste fica claro na própria documentação da AWS. aws-eusc é uma partição separada. Contas e credenciais de outra partição não são reaproveitadas automaticamente. S3 Cross-Region Replication e o peering inter-regional do Transit Gateway não funcionam entre partições. A separação que protege o limite soberano também elimina continuidades que um plano de recuperação entre regiões comerciais costuma presumir.

Cinco continuidades do cliente

A primeira é a continuidade de autoridade. O alvo precisa de contas, organização, papéis, políticas e operadores próprios. A decisão de ativá-lo deve continuar válida se a origem estiver tecnicamente indisponível ou juridicamente proibida. Uma conta criada durante a crise não é um estado de prontidão.

A segunda é a continuidade de confiança. Identidades de serviço, segredos, certificados, emissão, renovação e revogação precisam funcionar sem depender do plano de controle que o cenário elimina. Infraestrutura como código pode recriar recursos, mas não transporta por si só a cadeia de confiança.

A terceira é a continuidade de transporte. A AWS discute TLS pela internet, VPN IPsec e arranjos associados ao Direct Connect. É preciso testar endereçamento, rotas, filtros, DNS, chaves e responsabilidade operacional durante a falha escolhida. Um caminho que funciona enquanto todos os provedores e administradores estão disponíveis não prova a recuperação sob isolamento.

A quarta é a continuidade de estado. Como a replicação S3 nativa entre regiões não atravessa partições, o comprador precisa especificar sua sincronização, exportação ou restauração. Deve conhecer o ponto de consistência, o volume, o atraso, a autorização para transferir e o tempo para transformar a cópia em um serviço utilizável. Backup preservado não é aplicação recuperada.

A quinta é a continuidade de capacidade. A AWS apresenta um conjunto amplo de serviços e uma matriz de capacidades, mas a lista não comprova equivalência de API, função, tipo de instância, quota ou dependência gerenciada. Uma região multizona pode ser resiliente no nível da infraestrutura enquanto a conta do cliente não possui recursos suficientes para subir o workload.

A responsabilidade não termina na fronteira da AWS

Na orientação Well-Architected, a AWS separa resiliência da nuvem e resiliência na nuvem. Ela responde pela infraestrutura; o cliente define e configura implantação em múltiplos locais, autorreparo, backups, replicação, rede, quotas, observabilidade, runbooks e testes. Uma plataforma operacional sob desconexão pode hospedar um sistema que não inicia porque o cliente não construiu essas continuidades.

Também é preciso separar disponibilidade comum e recuperação de desastre. Um problema dentro de uma zona pode ser absorvido por uma arquitetura multi-AZ. Uma perda de região pode ser tratada dentro da mesma partição. A indisponibilidade de identidade, uma restrição jurídica ou uma ruptura geopolítica pode exigir a partição soberana. Cada falha remove componentes diferentes; portanto, cada uma exige um alvo e um teste próprios.

A AWS define RTO como o tempo máximo aceitável entre interrupção e restauração e RPO como a idade máxima aceitável do último ponto recuperável. São objetivos da organização. Eles não estão embutidos na inauguração de uma região ou no escopo de uma certificação.

O escopo de conformidade é uma coluna, não a tabela inteira

A AWS descreve independência de governança, controle operacional, residência de dados e isolamento técnico em sua estrutura soberana. Também lista serviços no escopo atual de assurance e lembra que o cliente continua responsável por avaliar sua própria conformidade.

Esse material pode demonstrar que o destino é elegível. Não demonstra paridade funcional, quota, capacidade reservada ou um exercício concluído. Confundir as colunas permite que um controle forte de residência de dados cubra um vazio de recuperação.

Nenhuma das fontes citadas revela inventário, quotas, volume de dados, consistência, RTO, RPO, teste, rollback ou custo de um comprador. Elas tampouco provam que um workload regulado identificado tenha realizado failover entre partições. A declaração verificável termina nos requisitos e nas limitações publicadas pela AWS.