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*
- ** **Tempo para implantação ****
- **Perguntas sobre a definição do requisito:** Qual é o cronograma necessário para a implantação? Horas, dias, semanas ou meses?
- **Respostas:** + **Desenvolvimento/teste:** 1 mês
+ **Produção:** 3 meses
- ** **Segurança** **
- **Perguntas sobre a definição do requisito:** 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? / **Respostas:** + **Desenvolvimento/teste:** Site-to-Site VPN aceitável
+ **Produção:** Rede privada necessária
- **Perguntas sobre a definição do requisito:** Ao aproveitar as conexões de rede privada, a camada de rede precisa fornecer criptografia em trânsito? / **Respostas:** Não, a criptografia da camada de aplicativo será usada.
- ** **SLA** **
- **Perguntas sobre a definição do requisito:** É necessário um SLA de conectividade híbrida com créditos de serviço? / **Respostas:** + **Desenvolvimento/teste**: Não
+ **Produção:** Sim
- **Perguntas sobre a definição do requisito:** Qual é a meta de tempo de atividade? / **Respostas:** + **Desenvolvimento/teste**: N/D
+ **Produção:** 99,99%
- **Perguntas sobre a definição do requisito:** Toda a rede híbrida precisa cumprir uma meta de tempo de atividade? / **Respostas:** + **Desenvolvimento/teste**: N/D
+ **Produção:** Sim
- ** **Desempenho** **
- **Perguntas sobre a definição do requisito:** Qual é a taxa de transferência necessária? / **Respostas:** + **Desenvolvimento/teste:** 100 Mbps
+ **Produção:** 500 Mbps crescendo para 2 Gbps
- **Perguntas sobre a definição do requisito:** Qual é a latência máxima aceitável entre uma rede da AWS e uma rede on-premises? / **Respostas:** + **Desenvolvimento/teste:** Sem requisitos rígidos
+ **Produção:** Menos de 30 ms
- **Perguntas sobre a definição do requisito:** Qual é a instabilidade de rede máxima aceitável? / **Respostas:** + **Desenvolvimento/teste:** Sem requisitos rígidos
+ **Produção:** Jitter mínima necessária
- ** **Custos** **
- **Perguntas sobre a definição do requisito:** Quantos dados você enviaria para a AWS por mês? / **Respostas:** + **Desenvolvimento/teste:** 2 TB
+ **Produção:** 20 TB crescendo para 50 TB
- **Perguntas sobre a definição do requisito:** Quantos dados você enviaria da AWS por mês? / **Respostas:** + **Desenvolvimento/teste:** 1 TB
+ **Produção:** 10 TB crescendo para 25 TB
- **Perguntas sobre a definição do requisito:** Essa conectividade é permanente? / **Respostas:** 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](https://aws.amazon.com/directconnect/sla/), eles selecionaram conexões dedicadas do Direct Connect.
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*
- ** **Escalabilidade** **
- **Perguntas sobre a definição do requisito:** Qual é o número atual ou previsto de VPCs que exigem conectividade com sites on-premises? / **Respostas:** 2 inicialmente, crescendo para 30 em 6 meses
- **Perguntas sobre a definição do requisito:** As VPCs são implantadas em uma Região da AWS única ou em várias regiões? / **Respostas:** Região única
- **Perguntas sobre a definição do requisito:** Quantos sites on-premises precisam estar conectados à AWS? / **Respostas:** 2 datacenters
- **Perguntas sobre a definição do requisito:** Quantos dispositivos de gateway do cliente você tem por site que precisam ser conectados à AWS? / **Respostas:** 2 roteadores por datacenter
- **Perguntas sobre a definição do requisito:** 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? / **Respostas:** + **Rotas a serem anunciadas para a AWS**: 20 rotas
+ **Rotas a serem recebidas da AWS**: 1 rota de `/16`
- **Perguntas sobre a definição do requisito:** Existe algum plano para considerar o aumento da largura de banda da conexão com a AWS em um futuro próximo? / **Respostas:** + **Desenvolvimento/teste:** 100 Mbps
+ **Produção:** 500 Mbps crescendo para 2 Gbps.
- ** **Modelos de design de conectividade** **
- **Perguntas sobre a definição do requisito:** Há um requisito para que a comunicação entre VPCs seja habilitada (dentro de uma região e/ou entre regiões)? / **Respostas:** Sim, dentro de uma Região da AWS
- **Perguntas sobre a definição do requisito:** Há algum requisito para acessar serviços de endpoints públicos da AWS diretamente on-premises? / **Respostas:** Sim
- **Perguntas sobre a definição do requisito:** Há um requisito para acessar serviços da AWS usando endpoints da VPC on-premises? / **Respostas:** 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.
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*
- ** Confiabilidade **
- **Perguntas sobre a definição do requisito:** Qual é a magnitude do impacto nos negócios em caso de falha de conectividade com a AWS? / **Respostas:** + **Desenvolvimento/teste**: Baixa
+ **Produção**: Alta
- **Perguntas sobre a definição do requisito:** 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? / **Respostas:** + **Desenvolvimento/teste**: Não
+ **Produção:** Sim
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.
