O blog da AWS
Como executar o Microsoft Exchange Server na AWS usando Amazon EC2
Neste blogpost, abordaremos a arquitetura de como executar o Microsoft Exchange em instâncias Windows do Amazon Elastic Compute Cloud (EC2) e também sobre como executar controladores de domínio do Microsoft Active Directory em instâncias EC2. Caso você já tenha o Active Directory (AD) sendo executado em seu Datacenter, essa abordagem permitirá que você estenda seu domínio do AD para a nuvem da AWS, adicionando controladores de domínio que são executados em instâncias EC2 Windows. Após a configuração de seus controladores de domínio do AD na AWS, você poderá executar cargas de trabalho do Windows na nuvem, além do Microsoft Exchange Server. Ao hospedar o Microsoft Exchange na AWS, você irá manter o controle sobre seus dados de e-mail enquanto aproveita a escalabilidade, a confiabilidade e o desempenho da nuvem da AWS.
Vamos começar analisando como o Microsoft Exchange pode ser implementado na AWS.
Diagrama de arquitetura do Microsoft Exchange na AWS
No diagrama a seguir, criamos um cenário em que a empresa estendeu sua floresta do Active Directory (corp.example.com) para a AWS adicionando controladores de domínio na AWS. A Exchange Organization (estrutura de dados do Exchange no AD) da empresa também foi estendida para a AWS com a adição de servidores Exchange na AWS. Depois de estender seus ambientes on-premises do Active Directory e do Exchange para a AWS, você pode facilmente mover as caixas de correio dos usuários para o novo ambiente.
Na arquitetura acima, o Microsoft Exchange é executado em instâncias do Amazon EC2 na mesma floresta do Active Directory que executa on-premises. Essa arquitetura é comumente usada quando os clientes desejam mover alguns ou todos os servidores Exchange do datacenter para a nuvem da AWS. Alguns clientes também adotam essa abordagem durante o processo de atualização do ambiente Microsoft Exchange Server para uma versão mais recente na AWS. Para ajudar a modernizar suas cargas de trabalho do Microsoft Exchange Server, oferecemos serviços profissionais da AWS e suporte à Rede de Parceiros da AWS.
Agora que sabemos como ficaria a arquitetura do Exchange rodando na AWS, vamos iniciar o tutorial.
Etapa 1: configurar a conectividade entre ambientes on-premises (seu Datacenter) e AWS
1.1 Estabeleça conectividade de rede
A primeira etapa é estabelecer conectividade de rede entre seu datacenter on-premises e a AWS. A maioria dos clientes escolhe uma das duas abordagens para estabelecer a conectividade:
- Uma conexão de rede privada virtual (VPN) site a site: Estabelece uma VPN pela Internet entre sua rede on-premises e a nuvem da AWS. Para mais detalhes veja o guia de introdução, que pode ser encontrado nesse Link.
- AWS Direct Connect: Estabelece uma conexão de rede direta entre sua rede on-premises e a AWS. Para mais detalhes veja o guia de introdução, que pode ser encontrado nesse link.
Geralmente, recomendamos a abordagem do Direct Connect em vez da conexão VPN para workloads de produção, como uma arquitetura híbrida do Active Directory e do Exchange. Isso ocorre porque o Direct Connect fornece latência mais previsível e largura de banda consistente entre seu datacenter e sua VPC. Consulte a documentação do AWS Direct Connect para obter mais informações.
Durante esse processo, é importante projetar as faixas de endereços IP (CIDR) para seu ambiente de nuvem da AWS para que eles não se sobreponham à sua rede on-premises. Em seguida, você deve estabelecer o roteamento de rede para que os pacotes possam ser roteados entre os ambientes on-premises e AWS.
Depois que as faixas de IP forem atribuídas, planeje os sites do Active Directory, os objetos das subnets do AD e os AD Site Links necessários para a rede criada na AWS.
1.2 Estabeleça uma resolução de DNS híbrida
Depois de estabelecer a conexão de rede, a próxima etapa é projetar a resolução de DNS entre seus servidores on-premises e os servidores na AWS, para que as consultas de DNS possam ser resolvidas para recursos on-premises ou na nuvem. Essa configuração é chamada de “arquitetura de DNS híbrida”.
Uma opção é alterar a configuração do servidor DNS nos servidores em execução na AWS para apontar para os endereços IP dos servidores DNS on-premises. Talvez você também precise adicionar o nome de domínio do AD à lista de sufixos DNS (veja a figura a seguir).
Figura 2: Adicione endereços de servidores DNS on-premises e acrescente sufixos DNS para o nome de domínio do AD
Depois que os servidores DNS forem configurados na AWS, essas configurações poderão ser atualizadas para apontar para os servidores DNS na AWS.
Se você tiver zonas privadas no Route 53 e precisar estabelecer um DNS híbrido, outra opção é usar Route 53 Resolvers. A postagem do blog, Novo — Amazon Route 53 Resolver para nuvens híbridas, discute como configurar o DNS híbrido e descreve como usar o Amazon Route 53 Outbound and Inbound Endpoints para habilitar o DNS híbrido entre on-premises e a AWS.
Para obter mais informações sobre o DNS híbrido, consulte este blog.
1.3 Estenda o Active Directory (AD) para a AWS
Depois de configurar a resolução de DNS híbrida entre recursos on-premises e na nuvem, a próxima etapa é estender seu Active Directory on-premises para a AWS. Para fazer essa etapa, configure novos servidores na AWS e promova-os para que se tornem controladores de domínio do AD. Os servidores podem ser promovidos para serem controladores de domínio no mesmo domínio do Active Directory on-premises ou para um novo domínio do AD na mesma floresta.
Durante o processo de promoção do controlador de domínio do AD, instale a função de servidor DNS no servidor. Essa ação permite que os controladores de domínio do AD resolvam consultas de DNS.
Depois que a função de servidor DNS for instalada nos controladores de domínio em execução na AWS, atualize as regras de encaminhamento condicional do endpoint do Route 53 Resolver Outbound para encaminhar consultas de DNS para o domínio AD DNS (por exemplo, corp.example.com) para esses novos servidores AD/DNS.
Nos servidores AD DC/DNS em execução na AWS, configure uma regra de encaminhamento de DNS para encaminhar consultas de DNS não resolvidas para o Route 53. O Route 53 tem a capacidade de hospedar zonas privadas, que são usadas pelos endpoints do AWS PrivateLink (veja aqui para obter mais informações). Portanto, se você quiser aproveitar os serviços de endpoint do PrivateLink, é importante modificar a configuração de DNS nos servidores AD/DNS para encaminhar consultas de DNS não resolvidas para o serviço Route 53 em vez dos servidores DNS raiz da Internet.
A captura de tela a seguir mostra a configuração do Forwarder no servidor AD/DNS. Definimos o endereço IP como “.2” da subnet (por exemplo, 10.0.0.2). O endereço “.2” é reservado pela AWS como servidor DNS da AWS (veja aqui para obter mais informações).
Figura 3: Definindo as configurações do encaminhador de servidor DNS do Windows
1.4 Estenda o Microsoft Exchange para a AWS
Depois que seu Active Directory for estendido para a AWS, a próxima etapa é configurar o Microsoft Exchange. Como a mesma floresta do Active Directory e o mesmo AD Schema existem no on-premises e na AWS, os servidores Microsoft Exchange na AWS podem fazer parte da mesma organização do Exchange que está on-premises. Para configurar o Exchange na AWS, configure servidores Windows em instâncias do Amazon EC2 (consulte o guia aqui), ingresse-os ao domínio do AD e instale os binários do Microsoft Exchange neles. Conforme mencionado anteriormente, muitos clientes aproveitam essa oportunidade para atualizar seu servidor Exchange para uma versão mais recente.
Os mesmos padrões de design usados na criação do Exchange on-premises também se aplicam à execução de servidores Exchange na AWS. Por exemplo, esses padrões de design incluem dimensionamento de servidores, uso da calculadora do Exchange, planejamento de namespaces, roteamento de mensagens e higiene de e-mails. Para obter mais informações, a Microsoft documentou essas melhores práticas em sua arquitetura preferencial do Exchange.
Depois que essas etapas forem concluídas, mova suas caixas de correio para os servidores Exchange que estão sendo executados na AWS. Comece migrando caixas de correio de teste antes de migrar caixas de correio de usuários reais.
Etapa 2: Criando um ambiente de laboratório do Exchange
O restante deste blog mostra como configurar um ambiente AD/Exchange em um ambiente de laboratório. Para ajudá-lo, a AWS criou um AWS Quick Start para o Microsoft Exchange. O Quick Start implanta dois servidores Microsoft Exchange em uma configuração de grupo de disponibilidade de banco de dados (DAG) com dois controladores de domínio do Active Directory, conforme mostrado no diagrama a seguir.
Figura 4: Ambiente do Exchange que será criado pelo AWS CloudFormation
Cada servidor e controlador de domínio do Exchange é criado em uma zona de disponibilidade (AZ) separada para resiliência.
Observe que você é responsável pelo custo dos serviços da AWS usados ao executar essa implantação de referência do Quick Start. A AWS fornece uma calculadora simples para estimar o custo da execução desse ambiente. Para minimizar o custo de execução do ambiente de teste, recomendo interromper as instâncias do EC2 no ambiente quando elas não estiverem em uso.
2.1 Instale o Microsoft Exchange usando o AWS Quick Start
Para instalar o AWS Quick Start para Microsoft Exchange, siga as instruções descritas em detalhes aqui. Depois que o template do Cloudformation para o QuickStart for concluído, continue para a próxima etapa. O processo do CloudFormation do QuickStart leva cerca de 90 minutos para ser concluído.
2.2 Conecte-se ao Microsoft Exchange
Em seguida, conecte-se ao servidor de gateway de Remote Desktop (RDGW) e ao servidor Microsoft Exchange.
- Conecte-se à instância RDGW. Para obter instruções sobre como se conectar, consulte Conectando-se à sua instância do Windows.
- Depois de fazer login no RDGW, você pode se conectar aos outros servidores no ambiente com o RDP. Ao configurar o template do AWS CloudFormation na Seção 3.1, você especificou o nome do domínio AD (no meu exemplo, exch.example.com), o nome de usuário do administrador do domínio (por exemplo, stackadmin) e a senha.
- No servidor RDGW, conecte-se ao servidor Exchange 1. Quando você estiver no servidor Exchange 1, inicie o Centro de Administração do Exchange. Você pode encontrar o Exchange Management Console na barra de inicialização do Windows (veja a captura de tela a seguir).
Figura 5: Inicie o Centro de Administração do Exchange a partir do menu de inicialização
Agora você deve conseguir acessar o Centro de Administração do Exchange.
Figura 6: Captura de tela do Centro de Administração do Exchange
Clean-up
Ao terminar o laboratório, você pode voltar ao AWS CloudFormation e selecionar a opção de excluir a stack do CloudFormation. Ao selecionar excluir, o AWS CloudFormation exclui os recursos que criou.
Resumo
Parabéns! Você aprendeu a configurar o Microsoft Exchange na AWS. No laboratório prático, você também adquiriu experiência usando a tecnologia de infraestrutura como código (IaC) da AWS chamada AWS CloudFormation, para automatizar a criação de um ambiente Microsoft Active Directory e Microsoft Exchange Server. Depois que o Exchange estiver configurado na AWS, você poderá usar as mesmas ferramentas de gerenciamento do AD e do Exchange que você usava no on-premises para gerenciar os servidores na AWS.
Para saber mais sobre a migração do Windows Server ou do SQL Server, visite o Windows na AWS. Para obter mais informações sobre como a AWS pode ajudar você a modernizar seus aplicativos antigos do Windows, consulte nossa página de modernização. Entre em contato conosco para começar sua jornada de modernização hoje mesmo.
Este artigo foi traduzido do Blog da AWS em Inglês.
Sobre o autor
Dean Suzuki é um gerente do time de arquitetos de soluções da AWS e gerencia uma equipe de arquitetos de soluções altamente qualificados cujo foco é ajudar os clientes a executar cargas de trabalho da Microsoft na AWS. Dean tem mais de 20 anos de experiência trabalhando com tecnologias da Microsoft e gosta de ajudar os clientes a obter os benefícios de executar suas cargas de trabalho na nuvem.
Revisores
Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.
Fernando Morelli é Arquiteto Senior de Soluções no time da AWS Public Sector. Trabalha com soluções de TI há mais de 25 anos, tendo em seu portifólio, experiências de migração de ambiente Microsoft para grande corporações privadas e públicas. Atualmente atua como arquiteto de soluções para o setor público, focando no governo Federal, provendo soluções AWS e suportando os órgãos Federais na jornada de implementação da nuvem AWS.
Maurício Trunfio é um Arquiteto de Soluções no time de AWS Large Enterprises. Trabalha com soluções de TI e nuvem há mais de 17 anos tendo em seu portfolio vasta experiencia com workloads Microsoft, especialmente SharePoint. Agora atuando como arquiteto de soluções para auxiliar os clientes a atingir seus objetivos rápida e eficientemente com a nuvem da AWS.