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á.
Exemplo de caso de uso da Corp. Automotive
Esta seção do whitepaper demonstra como as considerações, as questões de definição de requisitos e as árvores de decisão são usadas para ajudá-lo a decidir sobre o design ideal da rede híbrida. Identificar e capturar os requisitos é importante, pois eles são usados como entrada para as árvores de decisão. A captura antecipada dos requisitos evita novas iterações de design. A interrupção total de um projeto se o design precisar ser revisitado e a retenção de recursos valiosos pode ser minimizada e, idealmente, evitada quando os requisitos são entendidos de antemão.
O exemplo da Corp. Automotive será usada em toda esta seção como cliente ilustrativo. Eles pretendem implantar inicialmente seu primeiro projeto de análise na AWS. O projeto de análise está focado na análise de dados de carros fabricados pela empresa e outros conjuntos de dados que já existem nos datacenters da empresa. Inicialmente, o grupo de arquitetura da empresa acha que precisará de uma Conta da AWS, uma Amazon VPC e algumas sub-redes para hospedar ambientes de produção e desenvolvimento. A equipe do projeto está ansiosa para começar e solicitou acesso ao ambiente de desenvolvimento o mais rápido possível. Eles pretendem entrar em produção daqui a três meses.
Exemplo: A Corp. Automotive também planeja usar a AWS em vários projetos adicionais, como a migração de seus sistemas ERP, Virtual Desktop Infrastructure (VDI) e outros 20 aplicativos on-premises para a AWS nos próximos 6 meses. Alguns requisitos para projetos adicionais ainda estão sendo definidos, mas está claro que seu uso da Nuvem AWS vai crescer.
A equipe de arquitetura decidiu aproveitar a abordagem descrita neste whitepaper. Eles usaram as questões de definição de requisitos descritas em cada consideração para capturar as informações para tomar suas decisões de design.
Eles começam com requisitos relacionados ao tipo de conectividade resumidos na tabela a seguir.
Tabela 4 – Exemplo de entradas de confiabilidade da corporação automotiva
| Considerações sobre seleção do tipo de conectividade | Perguntas sobre a definição do requisito | Respostas |
|---|---|---|
| Tempo para implantação | Qual é o cronograma necessário para a implantação? Horas, dias, semanas ou meses? |
|
| Segurança | Seus requisitos e políticas de segurança permitem o uso de conexões criptografadas pela Internet para conexão com a AWS, ou exigem o uso de conexões de rede privadas? |
|
| Ao aproveitar as conexões de rede privada, a camada de rede precisa fornecer criptografia em trânsito? | Não, a criptografia da camada de aplicativo será usada. | |
| SLA | É necessário um SLA de conectividade híbrida com créditos de serviço? |
|
| Qual é a meta de tempo de atividade? |
|
|
| Toda a rede híbrida precisa cumprir uma meta de tempo de atividade? |
|
|
| Desempenho | Qual é a taxa de transferência necessária? |
|
| Qual é a latência máxima aceitável entre uma rede da AWS e uma rede on-premises? |
|
|
| Qual é a instabilidade de rede máxima aceitável? |
|
|
| Custos | Quantos dados você enviaria para a AWS por mês? |
|
| Quantos dados você enviaria da AWS por mês? |
|
|
| Essa conectividade é permanente? | Sim |
Com base nos requisitos recebidos, a equipe de arquitetura seguiu a árvore decisória do tipo de conectividade da Figura 9. Isso permitiu que a equipe de arquitetura decidisse sobre o tipo de conectividade para os ambientes de desenvolvimento, teste e produção. Para o ambiente de produção, eles consideraram os requisitos imediatos e futuros. Para desenvolvimento e teste, a Corp. Automotive estabelecerá uma VPN site a site pela Internet. Para a produção, eles trabalharão com um provedor de serviços para conectar sua rede corporativa com o AWS Direct Connect. A Corp. Automotive inicialmente considerou usar uma Conexão hospedada do Direct Connect; no entanto, devido aos requisitos de um SLA específico da AWS
Depois de decidir sobre o tipo de conectividade, a próxima etapa é capturar os requisitos que afetam a seleção do design de conectividade. Isso está relacionado ao design lógico, como as conexões são configuradas e quais serviços da AWS usar para dar suporte aos requisitos comerciais e técnicos.
Para capturar os requisitos do modelo de escalabilidade e comunicação, a equipe de arquitetura usou as perguntas de definição de requisitos das seções associadas deste whitepaper. Os requisitos relacionados a essas duas considerações estão resumidos na tabela a seguir.
Tabela 5 – perguntas sobre a definição de requisitos
| Considerações sobre seleção do design de conectividade | Perguntas sobre a definição do requisito | Respostas |
|---|---|---|
| Escalabilidade | Qual é o número atual ou previsto de VPCs que exigem conectividade com sites on-premises? | 2 inicialmente, crescendo para 30 em 6 meses |
| As VPCs são implantadas em uma Região da AWS única ou em várias regiões? | Região única | |
| Quantos sites on-premises precisam estar conectados à AWS? | 2 datacenters | |
| Quantos dispositivos de gateway do cliente você tem por site que precisam ser conectados à AWS? | 2 roteadores por datacenter | |
| Quantas rotas espera-se serem anunciadas para as AWS VPCs e qual é o número de rotas esperadas a serem recebidas do lado da AWS? |
|
|
| Existe algum plano para considerar o aumento da largura de banda da conexão com a AWS em um futuro próximo? |
|
|
| Modelos de design de conectividade | Há um requisito para que a comunicação entre VPCs seja habilitada (dentro de uma região e/ou entre regiões)? | Sim, dentro de uma Região da AWS |
| Há algum requisito para acessar serviços de endpoints públicos da AWS diretamente on-premises? | Sim | |
| Há um requisito para acessar serviços da AWS usando endpoints da VPC on-premises? | Não |
Com base nas entradas, a equipe de arquitetura seguiu a árvore de decisão da seção Design de conectividade. Depois de prever que o número de VPCs crescerá de 2 para 30 nos próximos 6 meses, a equipe de arquitetura decidiu usar o AWS Transit Gateway como gateway de terminação para a conexão e para o roteamento entre VPCs. AWS Transit Gateways independentes encerrarão a conexão VPN usada para desenvolvimento e teste, e para a conectividade de produção com o AWS Direct Connect. O uso de AWS Transit Gateways separados simplifica o gerenciamento de mudanças e fornece uma demarcação clara entre os ambientes de desenvolvimento/teste e produção. Para a produção, o gateway de AWS Direct Connect é necessário por causa do AWS Transit Gateway. Um VIF público será usado para acessar serviços de endpoint públicos da AWS. A Figura 14 ilustra o caminho percorrido na árvore de decisão com base nos requisitos coletados.
Figura 14 – Árvore de decisão do design de conexão da Corp. Automotive
Depois de decidir sobre a solução para atender aos requisitos do modelo de escalabilidade e comunicação, a próxima etapa é capturar os requisitos associados à confiabilidade. Isso está relacionado ao nível exigido de disponibilidade e resiliência.
Para capturar os requisitos confiabilidade, a equipe de arquitetura usou as perguntas de definição de requisitos da seção associada deste whitepaper. Os requisitos estão resumidos na tabela a seguir.
Tabela 6 – Perguntas sobre requisitos de confiabilidade
| Considerações sobre seleção do design de conectividade | Perguntas sobre a definição do requisito | Respostas |
|---|---|---|
| Confiabilidade | Qual é a magnitude do impacto nos negócios em caso de falha de conectividade com a AWS? |
|
| Do ponto de vista comercial, o custo de acompanhar uma falha de conectividade com a AWS supera o custo da implantação de um modelo de conectividade altamente confiável para a AWS? |
|
Com base nas informações recebidas, a equipe de arquitetura seguiu a árvore de decisão das seções de considerações de confiabilidade abordadas anteriormente neste whitepaper. Depois de considerar a meta de tempo de atividade de 99,99% para a conectividade de produção e o alto impacto nos negócios se houvesse uma interrupção do serviço, a equipe de arquitetura decidiu usar 2 locais do Direct Connect e ter 2 links de cada data center local para cada local do Direct Connect (4 links no total). A conectividade VPN usada para desenvolvimento e teste também usará duas conexões VPN para redundância adicional. Usando as técnicas de engenharia de rotas discutidas na seção de confiabilidade, a conectividade será configurada da seguinte forma:
-
Para desenvolvimento e teste, a carga do tráfego será balanceada usando ECMP nos 2 túneis que vão para o datacenter primário. Isso permite uma maior throughput. Os túneis que vão para o data center secundário serão usados em caso de falha dos túneis primários.
-
Para produção, a latência entre on-premises e AWS em qualquer um dos locais do Direct Connect é muito semelhante. Nesse caso, foi decidido balancear a carga do tráfego entre AWS e on-premises nas duas conexões que vão para o datacenter principal para os sistemas on-premises implantados no datacenter primário. Da mesma forma, para sistemas locais executados no datacenter secundário, a throughput será balanceada entre as duas conexões com o datacenter secundário. Em caso de falha nas conexões, o BGP facilitará um failover automático.
A Figura 15 ilustra o caminho percorrido na árvore de decisão com base nos requisitos coletados.
Figura 15 – Árvore de decisão de confiabilidade da Corp. Automotive
