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á.

Apêndice A - Orientação de serviço particional

Para serviços particionais, você deve implementar a estabilidade estática para manter a resiliência de sua carga de trabalho durante uma falha no plano de controle AWS de serviço. O seguinte fornece orientação prescritiva sobre como considerar as dependências de serviços particionais, bem como o que funcionará ou não durante uma falha no plano de controle.

AWS Identity and Access Management (IAM)

O plano de controle AWS Identity and Access Management (IAM) consiste em todas as APIs públicas do IAM (incluindo o Access Advisor, mas não o Access Analyzer ou o IAM Roles Anywhere). Isso inclui ações como CreateRoleAttachRolePolicy, ChangePasswordUpdateSAMLProvider,, UpdateLoginProfile e. O plano de dados do IAM fornece autenticação e autorização para os diretores do IAM em cada umRegião da AWS. Durante uma interrupção do plano de controle, as operações do tipo CRUDL para IAM podem não funcionar, mas a autenticação e a autorização dos diretores existentes continuarão funcionando. O STS é um serviço exclusivo de plano de dados que é separado do IAM e não depende do plano de controle do IAM.

O que isso significa é que, ao planejar dependências no IAM, você não deve confiar no plano de controle do IAM em seu caminho de recuperação. Por exemplo, um design estaticamente estável para um usuário administrador “revolucionário” seria criar um usuário com as permissões apropriadas anexadas, ter a senha definida, provisionar a chave de acesso e a chave de acesso secreta e, em seguida, bloquear essas credenciais em um cofre físico ou virtual. Quando necessário durante uma emergência, recupere as credenciais do usuário do cofre e use-as conforme necessário. Um non-statically-stable design seria provisionar o usuário durante uma falha ou pré-provisionar o usuário, mas anexar a política administrativa somente quando necessário. Essas abordagens dependeriam do plano de controle do IAM.

AWS Organizations

O plano AWS Organizations de controle consiste em todas as APIs de Organizations públicas AcceptHandshakeAttachPolicy, comoCreateAccount,CreatePolicy,, e. ListAccounts Não há um plano de dados paraAWS Organizations. Ele orquestra o plano de dados para outros serviços, como o IAM. Durante uma interrupção do plano de controle, as operações do tipo CRUDL para Organizations podem não funcionar, mas as políticas, como as Políticas de Controle de Serviços (SCP) e as Políticas de Etiquetas, continuarão funcionando e sendo avaliadas como parte do processo de autorização do IAM. Os recursos administrativos delegados e os recursos de várias contas em outros AWS serviços que são suportados pelas Organizations também continuarão funcionando.

O que isso significa é que, ao planejar dependênciasAWS Organizations, você não deve confiar no plano de controle da Organizations em seu caminho de recuperação. Em vez disso, implemente estabilidade estática em seu plano de recuperação. Por exemplo, uma non-statically-stable abordagem pode ser atualizar os SCPs para remover as restrições permitidas Regiões da AWS por meio da aws:RequestedRegion condição ou habilitar permissões de administrador para funções específicas do IAM. Isso depende do plano de controle Organizations para fazer essas atualizações. Uma abordagem melhor seria usar tags de sessão para conceder o uso de permissões de administrador. Seu provedor de identidade (IdP) pode incluir tags de sessão que podem ser avaliadas em relação à aws:PrincipalTag condição, o que ajuda você a configurar dinamicamente as permissões para determinados diretores e, ao mesmo tempo, ajudar seus SCPs a permanecerem estáticos. Isso remove as dependências dos planos de controle e utiliza somente ações do plano de dados.

AWS Account Management

O plano de controle de gerenciamento de AWS contas está hospedado em us-east-1 e consiste em todas as APIs públicas para gerenciar umConta da AWS, como e. GetContactInformation PutContactInformation Também inclui a criação ou o fechamento de um novo Conta da AWS por meio do console de gerenciamento. As APIs deCloseAccount, CreateAccountCreateGovCloudAccount, e DescribeAccount fazem parte do plano de AWS Organizations controle, que também está hospedado em us-east-1. Além disso, a criação de uma GovCloud conta externa AWS Organizations depende do plano de controle Conta da AWS de gerenciamento em us-east-1. Além disso, GovCloud as contas devem ser vinculadas 1:1 a uma Conta da AWS na aws partição. A criação de contas na a aws-cn sua. A sua principal rede do U. O plano de dados Contas da AWS é para as contas em si. Durante uma falha no plano de controle, as operações do tipo CRUDL (como criar uma nova conta ou obter e atualizar informações de contato) podem não funcionar. Contas da AWS As referências à conta nas políticas do IAM continuarão funcionando.

O que isso significa é que, ao planejar dependências no Gerenciamento de AWS Contas, você não deve confiar no plano de controle do Gerenciamento de Contas em seu caminho de recuperação. Embora o plano de controle do Gerenciamento de Contas não forneça a funcionalidade direta que você normalmente usaria em uma situação de recuperação, pode haver momentos em que você o faria. Por exemplo, um design estaticamente estável seria pré-provisionar tudo o que você precisa para o Contas da AWS failover. Um non-statically-stable projeto seria criar um novo Contas da AWS durante um evento de falha para hospedar seus recursos de DR.

Controlador de recuperação de aplicações do Route 53

O plano de controle do Route 53 ARC consiste em APIs para controle de recuperação e prontidão para recuperação, conforme identificado em: endpoints e cotas do Amazon Route 53 Application Recovery Controller. Você gerencia verificações de prontidão, controles de roteamento e operações de cluster usando o plano de controle. O plano de dados do ARC é seu cluster de recuperação, que gerencia os valores de controle de roteamento que são consultados pelas verificações de integridade do Route 53 e também implementa as regras de segurança. A funcionalidade do plano de dados do Route 53 ARC é acessada por meio de suas APIs de cluster de recuperação, comohttps://aaaaaaaa.route53-recovery-cluster.eu-west-1.amazonaws.com.

O que isso significa é que você não deve confiar no plano de controle ARC do Route 53 em seu caminho de recuperação. Há duas melhores práticas que ajudam a implementar essa orientação:

Gerenciador de rede AWS

O serviço AWS Network Manager é principalmente um sistema somente de plano de controle hospedado em us-west-2. A sua principal rede do Transit Gateway A sua principal rede do Transit Nuvem AWS Gateway entre Contas da AWS regiões e locais on-premises da. A sua principal rede do AWS Transit Gateway entre regiões e locais on-premises da. Ele também agrega suas métricas de Cloud WAN em us-west-2, que também podem ser acessadas por meio do CloudWatch plano de dados. Se o Network Manager estiver comprometido, o plano de dados dos serviços que ele orquestra não será afetado. As CloudWatch métricas para Cloud WAN também estão disponíveis em us-west-2. Se você quiser dados métricos históricos, como bytes de entrada e saída por região, para entender quanto tráfego pode ser transferido para outras regiões durante uma falha que afeta us-west-2, ou para outros fins operacionais, você pode exportar essas métricas como dados CSV diretamente do CloudWatch console ou usando este método: publicar CloudWatch métricas da Amazon em um arquivo CSV. Os dados podem ser encontrados no AWS/Network Manager namespace e você pode fazer isso de acordo com um cronograma de sua escolha e armazená-los no S3 ou em outro armazenamento de dados selecionado. Para implementar um plano de recuperação estaticamente estável, não use o AWS Network Manager para fazer atualizações em sua rede nem confie nos dados das operações do plano de controle para entrada de failover.

DNS privado do Route 53

As zonas hospedadas privadas do Route 53 são suportadas em cada partição; no entanto, as considerações para zonas hospedadas privadas e zonas hospedadas públicas no Route 53 são as mesmas. Consulte o Amazon Route 53 no Apêndice B — Orientação de serviço global da rede Edge.