As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Serviços globais

Além dos AWS serviços regionais e zonais, há um pequeno conjunto de AWS serviços cujos planos de controle e planos de dados não existem de forma independente em cada região. Como seus recursos não são específicos da região, eles são comumente chamados de globais. AWS Os serviços globais ainda seguem o padrão de AWS projeto convencional de separar o plano de controle e o plano de dados para obter estabilidade estática. A diferença significativa para a maioria dos serviços globais é que seu plano de controle é hospedado em um único plano Região da AWS, enquanto seu plano de dados é distribuído globalmente. Há três tipos diferentes de serviços globais e um conjunto de serviços que podem parecer globais com base na configuração selecionada.

As seções a seguir identificarão cada tipo de serviço global e como seus planos de controle e planos de dados são separados. Você pode usar essas informações para orientar como criar mecanismos confiáveis de alta disponibilidade (HA) e recuperação de desastres (DR) sem precisar depender de um plano de controle de serviço global. Essa abordagem ajuda a remover pontos únicos de falha em sua arquitetura e evita possíveis impactos entre regiões, mesmo quando você está operando em uma região diferente de onde o plano de controle de serviço global está hospedado. Também ajuda você a implementar com segurança mecanismos de failover que não dependem de planos de controle de serviço global.

Serviços globais que são exclusivos por partição

Alguns AWS serviços globais existem em cada partição (referidos neste paper como serviços particionais). Os serviços particionais fornecem seu plano de controle em um único Região da AWS. Alguns serviços particionais, como o AWS Network Manager, são somente do plano de controle e orquestram o plano de dados de outros serviços. Outros serviços particionais, comoIAM, têm seu próprio plano de dados, isolado e distribuído em todos os da Regiões da AWS partição. Falhas em um serviço particional não afetam outras partições. Na aws partição, o plano de controle do IAM serviço está na us-east-1 Região, com planos de dados isolados em cada Região da partição. Os serviços particionais também têm planos de controle e planos de dados independentes nas aws-cn partições aws-us-gov e. A separação do plano de controle e do plano de dados para IAM é mostrada no diagrama a seguir.

A seguir estão os serviços particionais e sua localização no plano de controle na aws partição:

Se algum desses planos de controle de serviço tiver um evento que afete a disponibilidade, talvez você não consiga usar as operações do CRUDL tipo -fornecidas por esses serviços. Portanto, se sua estratégia de recuperação depender dessas operações, um impacto na disponibilidade do plano de controle ou na região que hospeda o plano de controle reduzirá suas chances de recuperação bem-sucedida. Apêndice A - Orientação de serviço particionalfornece estratégias para remover dependências em planos de controle de serviços globais durante a recuperação.

Serviços globais na rede de ponta

O próximo conjunto de AWS serviços globais tem um plano de controle na aws partição e hospeda seus planos de dados na infraestrutura de pontos de presença globais (PoP) (e potencialmente Regiões da AWS também). Os planos de dados hospedados PoPs podem ser acessados a partir de recursos em qualquer partição, bem como na Internet. Por exemplo, o Route 53 opera seu plano de controle na us-east-1 região, mas seu plano de dados é distribuído em centenas de PoPs países, bem como em cada um deles Região da AWS (para oferecer suporte ao Route 53 público e privado na DNS região). As verificações de integridade do Route 53 também fazem parte do plano de dados e são executadas a partir de oito Regiões da AWS na aws partição. Os clientes podem resolver DNS usando zonas hospedadas públicas do Route 53 de qualquer lugar na Internet, incluindo outras partições GovCloud, como, bem como de uma nuvem privada AWS virtual (VPC). A seguir estão os serviços de rede de borda global e sua localização no plano de controle na aws partição:

Se você usa verificações de AGA saúde para EC2 instâncias ou endereços IP elásticos, eles usam verificações de saúde do Route 53. Criar ou atualizar verificações de AGA saúde dependeria do plano de controle do Route 53 emus-east-1. A execução das verificações de AGA saúde utiliza o plano de dados de verificação de saúde do Route 53.

Durante uma falha afetando a região que hospeda os planos de controle desses serviços, ou uma falha afetando o próprio plano de controle, talvez você não consiga usar as operações do CRUDL tipo -fornecidas por esses serviços. Se você depender dessas operações em sua estratégia de recuperação, essa estratégia pode ter menos probabilidade de sucesso do que se você confiasse apenas no plano de dados desses serviços.

Operações globais em uma única região

A categoria final é composta por operações específicas do plano de controle dentro de um serviço que tem um escopo de impacto global, não por serviços inteiros, como nas categorias anteriores. Enquanto você interage com serviços zonais e regionais na região especificada, determinadas operações têm uma dependência subjacente em uma única região que é diferente de onde o recurso está localizado. Eles são diferentes dos serviços fornecidos somente em uma única região; consulte Apêndice C - Serviços de região única para obter uma lista desses serviços.

Durante uma falha que afeta a dependência global subjacente, talvez você não consiga usar as ações do CRUDL tipo -das operações dependentes. Se você depender dessas operações em sua estratégia de recuperação, essa estratégia pode ter menos probabilidade de sucesso do que se você confiasse apenas no plano de dados desses serviços. Você deve evitar dependências dessas operações para sua estratégia de recuperação.

A seguir está uma lista de serviços dos quais outros serviços podem depender, que têm escopo global:

Serviços que usam endpoints globais padrão

Em alguns casos, os AWS serviços fornecem um endpoint global padrão, como o AWS Security Token Service (AWS STS). Outros serviços podem usar esse endpoint global padrão em sua configuração padrão. Isso significa que um serviço regional que você está usando pode ter uma dependência global de um único Região da AWS. Os detalhes a seguir explicam como remover dependências não intencionais em endpoints globais padrão que ajudarão você a usar o serviço de forma regional.

AWS STS: STS é um serviço web que permite que você solicite credenciais temporárias com privilégios limitados para IAM usuários ou para usuários que você autentica (usuários federados). STSo uso do kit de desenvolvimento de AWS software (SDK) e da interface de linha de comando (CLI) é padronizado como. us-east-1 O STS serviço também fornece endpoints regionais. Esses endpoints são ativados por padrão em regiões que também são ativadas por padrão. Você pode tirar proveito deles a qualquer momento configurando SDK ou CLI seguindo estas instruções: Endpoints AWS STSregionalizados. O uso do SIGv4a também requer credenciais temporárias solicitadas de um endpoint regional. STS Você não pode usar o STS endpoint global para essa operação.

Login da Security Assertion Markup Language (SAML): os SAML serviços existem em todos. Regiões da AWS Para usar esse serviço, escolha o SAML endpoint regional apropriado, como https://us-west-2.signin.aws.amazon.com/saml. Você deve fazer atualizações nas configurações em suas políticas de confiança e no Provedor de Identidade (IdP) para usar os endpoints regionais. Consulte a AWS SAMLdocumentação para obter detalhes específicos.

Se você estiver usando um IdP que também esteja hospedado AWS, existe o risco de que ele também seja afetado durante um AWS evento de falha. Isso pode fazer com que você não consiga atualizar sua configuração de IdP ou talvez não consiga federar totalmente. Você deve pré-provisionar usuários “quebra-vidro” caso seu IdP esteja comprometido ou indisponível. Consulte Apêndice A - Orientação de serviço particional para obter detalhes sobre como criar usuários de quebra-vidros de uma forma estaticamente estável.

AWS IAMIdentity Center: O Identity Center é um serviço baseado em nuvem que facilita o gerenciamento centralizado do acesso de login único aos aplicativos do cliente e da nuvem. Contas da AWS O Identity Center deve ser implantado em uma única região de sua escolha. No entanto, o comportamento padrão do serviço é usar o SAML endpoint global (https://signin.aws.amazon.com/saml), que está hospedado emus-east-1. Se você implantou o Identity Center em outro Região da AWS, você deve atualizar o estado de retransmissão URL de cada conjunto de permissões para atingir o mesmo endpoint de console regional da implantação do Identity Center. Por exemplo, se você implantou o Identity Center emus-west-2, você deve atualizar o estado de retransmissão dos seus conjuntos de permissões para usar https://us-west-2.console.aws.amazon.com. Isso removerá qualquer dependência us-east-1 da sua implantação do Identity Center.

Além disso, como o IAM Identity Center só pode ser implantado em uma única região, você deve pré-provisionar usuários “inovadores” caso sua implantação seja prejudicada. Consulte Apêndice A - Orientação de serviço particional para obter detalhes sobre como criar usuários de quebra-vidros de uma forma estaticamente estável.

Lente de armazenamento Amazon S3: o Storage Lens fornece um painel padrão chamado. default-account-dashboard A configuração do painel e suas métricas associadas são armazenadas emus-east-1. Você pode criar painéis adicionais em outras regiões especificando a região de origem para a configuração do painel e os dados métricos.

Resumo dos serviços globais

Os planos de dados para serviços globais aplicam princípios de isolamento e independência semelhantes aos AWS serviços regionais. Uma falha afetando o plano de dados IAM de uma região não afeta a operação do plano de IAM dados em outra Região da AWS. Da mesma forma, uma falha afetando o plano de dados do Route 53 em um PoP não afeta a operação do plano de dados do Route 53 no resto do PoPs. Portanto, o que devemos considerar são os eventos de disponibilidade de serviços que afetam a região onde o plano de controle opera ou afetam o próprio plano de controle. Como há apenas um único plano de controle para cada serviço global, uma falha que afeta esse plano de controle pode ter efeitos entre regiões nas operações do CRUDL tipo -( que são as operações de configuração normalmente usadas para instalar ou configurar um serviço, em oposição ao uso direto do serviço).

A maneira mais eficaz de arquitetar cargas de trabalho para usar serviços globais de forma resiliente é usar a estabilidade estática. Durante um cenário de falha, projete sua carga de trabalho para não precisar fazer alterações em um plano de controle para mitigar o impacto ou o failover em um local diferente. Consulte Apêndice A - Orientação de serviço particional e obtenha Apêndice B - Orientação de serviço global da rede Edge orientações prescritivas sobre como utilizar esses tipos de serviços globais para remover dependências do plano de controle e eliminar pontos únicos de falha. Se você precisar dos dados de uma operação do plano de controle para recuperação, armazene esses dados em um armazenamento de dados que possa ser acessado por meio de seu plano de dados, como um parâmetro do AWS Systems Manager Parameter Store (SSMParameter Store), uma tabela do DynamoDB ou um bucket do S3. Para redundância, você também pode optar por armazenar esses dados em uma região adicional. Por exemplo, seguindo as melhores práticas do Route 53 Application Recovery Controller (ARC), você deve codificar ou marcar seus cinco endpoints de cluster regionais como favoritos. Durante um evento de falha, talvez você não consiga acessar algumas API operações, incluindo operações do Route 53 ARC API que não estão hospedadas no cluster de plano de dados extremamente confiável. Você pode listar os endpoints dos seus ARC clusters do Route 53 usando a DescribeCluster API operação.

A seguir está um resumo de algumas das configurações incorretas ou antipadrões mais comuns que introduzem dependências nos planos de controle dos serviços globais:

A seguir está um resumo das recomendações fornecidas nesta seção para o uso de serviços globais de forma resiliente que ajudaria a evitar os antipadrões comuns anteriores.