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á.
Zona de pouso com uma única conta versus zona de pouso com várias contas FAQs
Algumas perguntas frequentes ao escolher configurar uma única zona de pouso com várias contas ou várias zonas de destino com várias contas:
P1: Posso começar com uma única landing zone com várias contas e passar para uma landing zone com várias contas, se houver algum limite de conta ou restrição comercial?
R: Sim. Você pode optar por configurar outra landing zone com várias contas a qualquer momento:
Será necessário configurar uma nova conta de pagador de faturamento (atualmente, a AWS não oferece suporte a contas com vários pagadores em uma única organização da AWS).
A construção da base da zona de aterrissagem com várias contas leva até 2 semanas após o preenchimento do questionário da zona de aterrissagem com várias contas.
Cada landing zone com várias contas significa um custo operacional adicional de aproximadamente 3 mil dólares/mês.
A integração N/W, AD, DNS e SSO será necessária para estabelecer o novo MALZ.
Quaisquer instâncias reservadas (RIs) e planos de economia de custos precisarão ser configurados para a nova landing zone de várias contas (não RIs são transferíveis).
A landing zone multiconta do AMS não oferece suporte à migração de uma conta entre contas de várias contas da landing zone; por exemplo, entre organizações da AWS. No entanto, é possível mover aplicativos de uma conta para outra usando métodos de migração padrão.
Q2: Qual é a abordagem da AMS à MALZ updates/changes para underlying/shared infraestrutura e quantificação do risco para os clientes? Forneça detalhes sobre quais garantias estão incluídas no processo. Como os clientes se sentem confortáveis de que o MALZ não updates/changes afetará os clientes? Há alguma medida que o Cliente precise tomar para evitar interrupções?
R: A AMS segue uma metodologia de mudança rígida usando ferramentas internas que nos permitem definir, revisar, programar e executar mudanças nos ambientes dos clientes.
O processo de lançamento de atualizações impõe análises de código, testes de integração, implantação em ambientes gama e beta, além de tempo adicional de preparação e testes em ambientes beta e gama antes do lançamento para os ambientes dos clientes. Todos os lançamentos incluem procedimentos de reversão e são monitorados de perto pela equipe de lançamentos e pela equipe que criou e solicitou a alteração. O escopo dos lançamentos está limitado às pilhas pertencentes e provisionadas pela AMS. Em média, executamos pelo menos uma versão por semana.
Além disso:
O AMS SLA é aplicável. De acordo com a descrição do serviço AMS, qualquer incidente gerado após a atividade compartilhada de manutenção de infraestrutura cumpriria o SLA autorizado para resolução ou créditos.
Nenhuma medida preventiva especial é exigida pelos Clientes para evitar interrupções na infraestrutura comum. Os clientes têm permissões de somente leitura nas contas AWS Org ou Core OU, portanto, os clientes não podem fazer alterações destrutivas no ambiente principal do MALZ. Todas as solicitações do cliente à infraestrutura principal exigem análise e aprovação do AMS.
Os clientes podem testar determinadas alterações no nível da organização, como SCPs/Roles em níveis individuais de contas não produtivas, antes de propagar as alterações no nível da OU do aplicativo. Está no roteiro do AMS permitir vários APP OUs (segundo trimestre de 2020), o que aliviaria ainda mais o risco de fazer algumas mudanças no nível da ORG. A equipe da MALZ já lançou uma OU separada para contas do “Modo Construção”, para garantir uma segregação clara da propriedade do cliente e controles separados.
A maioria dessas mudanças permitem que o AMS opere a carga de trabalho de maneira eficaz e eficiente e não necessariamente afeta a carga de trabalho dos clientes. Quando a AMS acredita que uma mudança de infraestrutura compartilhada pode ter um impacto na carga de trabalho dos clientes, ela é então alinhada à janela de mudança dos clientes.
Recomendação de alto nível, comece com várias zonas de destino com várias contas se:
Se isso ajudar você a obter alguma conformidade específica.
Se você precisar usar o Multi-Region.
Se você tiver diferentes cargas de trabalho locais ADs e de redes para Prod/Material cargas de trabalho externasProd/Non-Material workloads, to clearly segregate b/w.
