O blog da AWS

Como executar o Microsoft Exchange Server na AWS usando Amazon EC2

Por Dean Suzuki, gerente do time de arquitetos de soluções na AWS 
Me perguntaram: “É possível hospedar o Microsoft Exchange na AWS?” A resposta é sim!.

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.

Exchange and Active Directory Running in AWS on EC2

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:

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).

Add on-premises DNS servers’ addresses and append DNS suffixes for AD domain name

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).

Configuring the Windows DNS server forwarder settings

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.

  1. Conecte-se à instância RDGW. Para obter instruções sobre como se conectar, consulte Conectando-se à sua instância do Windows.
  2. 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.
  3. 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).

Launch Exchange Administrative Center from the startup menu

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.

Screenshot of Exchange Administration Center

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.