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á.
Escolhendo um único MALZ ou vários MALZs
A tabela a seguir fornece algumas considerações de alto nível sobre como decidir entre uma única zona de aterrissagem com várias contas (MALZ) e várias zonas de aterrissagem com várias contas (por exemplo, duas zonas de pouso com várias contas - Prod e não Prod). Em geral, a escolha depende das necessidades individuais, dos requisitos legais e das práticas operacionais.
| Entidade | Zona de pouso única do AMS | Várias (duas ou mais) zonas de pouso |
|---|---|---|
Custo base |
Menor, otimizado em aproximadamente $3.000 por mês. |
Mais alto, um custo adicional de aproximadamente $3.000 por ambiente. |
Faturamento |
Fatura única, devido a uma única conta de faturamento/gerenciamento. |
Fatura separada para cada landing zone com várias contas. Atualmente, a AWS Org não oferece suporte a contas de gerenciamento múltiplo com uma única fatura. |
Portabilidade das instâncias reservadas existentes () RIs |
Baixo. RIs Atualmente, a AWS não é conversível em várias contas de faturamento. Você reutilizaria a zona de pouso existente RIs para várias contas. |
Mais baixo. Você reutilizaria e distribuiria RIs em todas as landing zone de várias contas. |
Descontos por escalonamento de produtos |
Alta. Consulte Descontos por volume. |
Baixo. Consulte Descontos por volume. |
Sobrecarga de configuração inicial (nos project/migration cronogramas) |
Baixo. Integrações de Active Directory, rede e login único (SSO) apenas uma vez. |
Alta. Você executaria o Active Directory, a integração de rede e as integrações de SSO para cada landing zone. Isso pode causar possíveis atrasos em qualquer projeto de migração. |
Configurabilidade de serviços comuns |
Esforços baixos. Você configura common/shared serviços como DNS, backup, monitoramento, registro, etc. |
Grandes esforços. É necessário um planejamento adicional para abordar onde a infraestrutura ou os serviços comuns estarão localizados. O tráfego atravessando vários gateways de trânsito (TGWs) em cada landing zone pode gerar custos extras. |
Escalabilidade |
Médio. O AMS tem um limite prático atual de 150 contas por landing zone com várias contas. Várias equipes ou fornecedores executando aplicativos na mesma conta podem ter acesso a pilhas pertencentes a equipes diferentes. Essa limitação pode ser mitigada controlando o acesso às pilhas específicas do aplicativo na ServiceNow camada (integrando o aplicativo AMS ServiceNow Connector e fazendo uso de tags). Pergunte aos gerentes de entrega técnica (TDMs) ou arquitetos de nuvem (CAs) do AMS como implementar isso. |
Alta. Capacidade de aproveitar várias landing zone de várias contas para distribuir as contas e, ao mesmo tempo, atingir um nível de segregação de contas ou aplicativos. O gerenciamento de um grande número de contas pode gerar despesas operacionais ou de custos. |
Risco operacional |
(Depende) Baixo. Integração operacional e prontidão apenas uma vez. Menos chance de desvios no processo. |
(Depende) Baixo. Várias atividades operacionais e de integração. A deriva em várias zonas de pouso durante o período pode levar a riscos operacionais. |
Várias regiões da AWS |
Região única da AWS. A landing zone multiconta do AMS é restrita a uma única região da AWS. Para abranger várias regiões da AWS, use várias landing zone com várias contas. |
Várias regiões da AWS. Com várias zonas de aterrissagem com várias contas, você pode implantar cada MALZ em uma região e interconectá-las usando o peering de gateway de trânsito (TGW). |
Migração ou portabilidade da conta |
Sim. É possível mover contas de uma OU para outra dentro da mesma organização da AWS. |
Não. O AMS não suporta a migração de uma conta entre zonas de destino, ou seja, entre AWS Organizations. As cargas de trabalho podem alcançar várias zonas de aterrissagem com gateway de trânsito (TGW) ou emparelhamento de VPC. |
Gerenciamento de alterações |
Médio. Fazer alterações destrutivas em componentes comuns, como TGW, Active Directory (AD) ou outbound (egress), pode afetar todas as cargas de trabalho em uma landing zone com várias contas. No entanto, as alterações nos componentes gerenciados pelo AMS são testadas internamente e incluídas em atualizações contínuas. |
Baixo. Fazer alterações destrutivas em componentes comuns, como TGW, AD ou outbound (egress), pode afetar somente as cargas de trabalho nessa landing zone específica de várias contas. |
Controles de dados e acesso |
(Depende) Baixo controle se você quiser se conectar a diferentes redes locais e locais para cargas de trabalho produtivas ADs e não produtivas. A federação SAML, os domínios TGW e os grupos de segurança (SGs) também podem ajudar a implementar os controles necessários. |
(Depende) Alto controle se você quiser se conectar a diferentes redes locais e locais para cargas de trabalho produtivas ADs e não produtivas. Use zonas de pouso separadas para requisitos rigorosos de conformidade. |
Conformidade e segurança |
(Depende) Baixo se houver necessidades estritas de conformidade para separar completamente as cargas de trabalho materiais e não materiais. Controles preventivos e de detetive padrão da AMS em vigor. |
(Depende) Até mesmo uma landing zone com várias contas pode ajudar a atingir requisitos rígidos de conformidade ao separar completamente as cargas de trabalho materiais das não materiais. Controles preventivos e de detetive padrão da AMS em vigor. |
Recomendação: Sem conformidade estrita ou necessidade multirregional, começar com uma única landing zone com várias contas do AMS alcançaria um bom equilíbrio entre custo, segurança, excelência operacional e complexidade da migração. Você sempre pode configurar uma landing zone adicional, se alguma restrição de conta ou negócio for encontrada.
