Blog de Amazon Web Services (AWS)

Cómo ejecutar Microsoft Exchange Server en AWS usando Amazon EC2

Por Dean Suzuki, director del equipo de arquitectos de soluciones de AWS
Me preguntaron: «¿Es posible alojar Microsoft Exchange en AWS?» ¡La respuesta es sí!

En esta entrada de blog, analizaremos la arquitectura para ejecutar Microsoft Exchange en instancias de Windows de Amazon Elastic Compute Cloud (EC2) y también cómo ejecutar los controladores de dominio de Microsoft Active Directory en instancias EC2. Si ya tiene Active Directory (AD) en su centro de datos, este enfoque le permitirá extender su dominio de AD a la nube de AWS añadiendo controladores de dominio que se ejecutarán en instancias EC2 Windows. Tras configurar los controladores de dominio de AD en AWS, podrá ejecutar cargas de trabajo de Windows en la nube, además de en Microsoft Exchange Server. Al alojar Microsoft Exchange en AWS, mantendrá el control sobre sus datos de correo electrónico, aprovechando la escalabilidad, la confiabilidad y el rendimiento de la nube de AWS.

Empecemos por analizar cómo se puede implementar Microsoft Exchange en AWS.

Diagrama de arquitectura de Microsoft Exchange en AWS

En el siguiente diagrama, creamos un escenario en el que la empresa amplió su bosque de Active Directory (corp.example.com) a AWS añadiendo controladores de dominio en AWS. La organización Exchange de la empresa (estructura de datos de Exchange en AD) también se extendió a AWS con la incorporación de servidores Exchange en AWS. Una vez que haya extendido sus entornos locales de Active Directory y Exchange a AWS, podrá mover fácilmente los buzones de correo de los usuarios al nuevo entorno.
Exchange and Active Directory Running in AWS on EC2

En la arquitectura anterior, Microsoft Exchange se ejecuta en instancias de Amazon EC2 en el mismo bosque de Active Directory que se ejecuta localmente. Esta arquitectura se utiliza normalmente cuando los clientes desean trasladar algunos o todos los servidores de Exchange del centro de datos a la nube de AWS. Algunos clientes también adoptan este enfoque durante el proceso de actualización de su entorno de Microsoft Exchange Server a una versión más reciente en AWS. Para ayudar a modernizar sus cargas de trabajo de Microsoft Exchange Server, ofrecemos Servicios Profesionales de AWS y apoyamos la red de socios de AWS.

Ahora que sabemos cómo sería la arquitectura de Exchange si se ejecutara en AWS, comencemos con el tutorial.

Paso 1: Configure la conectividad entre los entornos locales (su centro de datos) y AWS

1.1 Establezca conectividad de red

El primer paso es establecer la conectividad de red entre el centro de datos local y AWS. La mayoría de los clientes eligen uno de los dos enfoques para establecer la conectividad:

En general, recomendamos el enfoque de Direct Connect en lugar de la conexión VPN para las cargas de trabajo de producción, como una arquitectura híbrida de Active Directory y Exchange. Esto se debe a que Direct Connect proporciona una latencia más predecible y un ancho de banda constante entre el centro de datos y la VPC. Consulte la documentación de AWS Direct Connect para obtener más información.

Durante este proceso, es importante diseñar los rangos de direcciones IP (CIDR) del entorno de nube de AWS para que no se superpongan con la red local. A continuación, debe establecer el enrutamiento de red para que los paquetes se puedan enrutar entre los entornos locales y de AWS.

Una vez se hayan asignado los rangos de IP, planifique los sitios de Active Directory, los objetos de subred de AD y los enlaces de sitios de AD necesarios para la red creada en AWS.

1.2 Establezca una resolución de DNS híbrida

Tras establecer la conexión de red, el siguiente paso es diseñar la resolución de DNS entre los servidores del centro de datos y los servidores de AWS, de modo que se puedan resolver las consultas de DNS para los recursos del centro de datos o en la nube. Esta configuración se denomina «arquitectura DNS híbrida».

Una opción es cambiar la configuración del servidor DNS en los servidores que se ejecutan en AWS para que apunte a las direcciones IP de los servidores DNS del centro de datos. Es posible que también necesite añadir el nombre de dominio de AD a la lista de sufijos DNS (consulte la siguiente figura).
Add on-premises DNS servers’ addresses and append DNS suffixes for AD domain name

Figura 2. Agregue direcciones de servidores DNS locales y sufijos DNS para el nombre de dominio de AD

 

Una vez que los servidores DNS estén configurados en AWS, estos ajustes se pueden actualizar para que apunten a los servidores DNS de AWS.

Si tiene zonas alojadas privadas en Route 53 y necesita establecer un DNS híbrido, otra opción es usar Route 53 Resolvers. La entrada del blog, Nuevo: Amazon Route 53 Resolver para clouds híbridas, explica cómo configurar el DNS híbrido y describe cómo utilizar los puntos de enlace de entrada y salida de Amazon Route 53 para habilitar el DNS híbrido entre el centro de datos y AWS.

Para obtener más información sobre el DNS híbrido, consulte este blog.

1.3 Extender Active Directory (AD) a AWS

Tras configurar la resolución de DNS híbrida entre los recursos del centro de datos y la nube, el siguiente paso es extender el Active Directory del centro de datos a AWS. Para realizar este paso, configure nuevos servidores en AWS y promuévalos para que se conviertan en controladores de dominio de AD. Los servidores se pueden promover para que sean controladores de dominio en el mismo dominio local de Active Directory o en un nuevo dominio de AD en el mismo bosque.

Durante el proceso de promoción del controlador de dominio de AD, instale la función de servidor DNS en el servidor. Esta acción permite a los controladores de dominio de AD resolver las consultas de DNS.

Una vez que la función de servidor DNS esté instalada en los controladores de dominio que se ejecutan en AWS, actualice las reglas de reenvío condicional de puntos de enlace de salida de Route 53 Resolver para reenviar las consultas de DNS del dominio DNS de AD (por ejemplo, corp.example.com) a estos nuevos servidores de AD/DNS.

En los servidores de AD DC/DNS que se ejecutan en AWS, configure una regla de reenvío de DNS para reenviar las consultas de DNS no resueltas a Route 53. Route 53 puede alojar zonas alojadas privadas, que utilizan los endpoints de AWS PrivateLink (consulte aquí para obtener más información). Por lo tanto, si desea aprovechar los endpoints de PrivateLink, es importante modificar la configuración de DNS de los servidores AD/DNS para reenviar las consultas DNS no resueltas al servicio Route 53 en lugar de a los servidores DNS raíz de Internet.

La siguiente captura de pantalla muestra la configuración del reenviador en el servidor AD/DNS. Configuramos la dirección IP en «.2» desde la subred (por ejemplo, 10.0.0.2). AWS reserva la dirección «.2» como servidor DNS de AWS (consulte aquí para obtener más información).

Configuring the Windows DNS server forwarder settings

Figura 3. Configuración de los parámetros del reenviador del servidor DNS de Windows

 

1.4 Extienda Microsoft Exchange a AWS

Una vez que su Active Directory se haya extendido a AWS, el siguiente paso es configurar Microsoft Exchange. Dado que el mismo bosque de Active Directory y el mismo esquema de AD existen en el centro de datos y en AWS, los servidores de Microsoft Exchange en AWS pueden formar parte de la misma organización de Exchange que se encuentra en las instalaciones. Para configurar Exchange en AWS, configure servidores Windows en instancias de Amazon EC2 (consulte la guía aquí), únalos al dominio de AD e instale los binarios de Microsoft Exchange en ellos. Como se mencionó anteriormente, muchos clientes aprovechan esta oportunidad para actualizar su servidor Exchange a una versión más reciente.

Los mismos patrones de diseño que se utilizan al crear Exchange en el centro de datos también se aplican a la ejecución de servidores de Exchange en AWS. Por ejemplo, estos patrones de diseño incluyen el tamaño de los servidores, el uso de la calculadora de Exchange, la planificación del espacio de nombres, el enrutamiento de mensajes y la higiene del correo electrónico. Para obtener más información, Microsoft documentó estas prácticas recomendadas en su arquitectura de Exchange preferida.

Una vez completados estos pasos, mueva los buzones de correo a los servidores de Exchange que se ejecutan en AWS. Comience por migrar los buzones de prueba antes de migrar los buzones de usuarios reales.

Paso 2: Creación de un entorno de laboratorio de Exchange

El resto de este blog muestra cómo configurar un entorno de AD/Exchange en un entorno de laboratorio. Para ayudarlo, AWS creó un AWS Quick Start para Microsoft Exchange. El Quick Start implementa dos servidores de Microsoft Exchange en una configuración de grupo de disponibilidad de bases de datos (DAG) con dos controladores de dominio de Active Directory, como se muestra en el siguiente diagrama.

Figura 4. Entorno de Exchange que creará AWS CloudFormation

 

Cada controlador de dominio y servidor de Exchange se crea en una zona de disponibilidad (AZ) independiente para garantizar la resiliencia.

Tenga en cuenta que es responsable del coste de los servicios de AWS creados al ejecutar esta Quick Start. AWS proporciona una calculadora sencilla para estimar el coste de ejecución de este entorno. Para minimizar el coste de ejecución del entorno de prueba, es recomendable detener las instancias de EC2 en el entorno cuando no estén en uso.

2.1 Instale Microsoft Exchange mediante AWS Quick Start

Para instalar el AWS Quick Start para Microsoft Exchange, siga las instrucciones que se describen en detalle aquí. Cuando la plantilla de Cloudformation para QuickStart termine, continúe con el paso siguiente. El proceso de CloudFormation de QuickStart tarda unos 90 minutos en completarse.

2.2 Conéctese a Microsoft Exchange

A continuación, conéctese al servidor Remote Desktop Gateway (RDGW) y al servidor Microsoft Exchange.

  1. Conéctese a la instancia de RDGW. Para obtener instrucciones sobre cómo conectarse, consulte Conectarse a la instancia de Windows.
  2. Una vez que inicie sesión en el RDGW, podrá conectarse a los demás servidores del entorno mediante RDP. Al configurar la plantilla de AWS CloudFormation en la sección 3.1, especificó el nombre del dominio de AD (en mi ejemplo, exch.example.com), el nombre de usuario del administrador del dominio (por ejemplo, stackadmin) y la contraseña.
  1. En el servidor RDGW, conéctese al servidor Exchange 1. Una vez que esté en el servidor de Exchange 1, inicie el Centro de administración de Exchange. Encontrará la Consola de administración de Exchange en la barra de inicio de Windows (consulte la captura de pantalla siguiente).

Launch Exchange Administrative Center from the startup menu

Figura 5. Inicie el Centro de administración de Exchange desde el menú de inicio

 

Ahora debería poder acceder al Centro de administración de Exchange.

Screenshot of Exchange Administration Center

Figura 6. Captura de pantalla del Centro de administración de Exchange

 

Clean-up

Cuando termine el laboratorio, puede volver a AWS CloudFormation y seleccionar la opción para eliminar el stack de CloudFormation. Al seleccionar eliminar, AWS CloudFormation elimina los recursos que ha creado.

 

Resumen

¡Enhorabuena! Aprendió a configurar Microsoft Exchange en AWS. En el laboratorio, también adquirió experiencia en el uso de la tecnología de infraestructura como código (IaC) de AWS denominada AWS CloudFormation para automatizar la creación de un entorno de Microsoft Active Directory y Microsoft Exchange Server. Una vez que Exchange esté configurado en AWS, puede usar las mismas herramientas de administración de AD y Exchange que usó localmente para administrar los servidores en AWS.

Para obtener más información sobre la migración desde Windows Server o SQL Server, visite Windows en AWS. Para obtener más información sobre cómo AWS puede ayudarlo a modernizar sus antiguas aplicaciones de Windows, consulte nuestra página de modernización. Póngase en contacto con nosotros para comenzar su proceso de modernización hoy mismo.

Este artículo fue traducido del Blog da AWS en Inglés.

 


Acerca del autor

Dean Suzuki es director del equipo de arquitectos de soluciones de AWS y dirige un equipo de arquitectos de soluciones altamente cualificados que se centran en ayudar a los clientes a ejecutar las cargas de trabajo de Microsoft en AWS.  Dean lleva más de 20 años de experiencia trabajando con tecnologías de Microsoft y disfruta ayudando a los clientes a obtener los beneficios de ejecutar sus cargas de trabajo en la nube.

 

 

 

 

Revisores

Bruno Lopes es arquitecto de soluciones sénior en el equipo de AWS LATAM. Lleva más de 14 años trabajando con soluciones de TI y cuenta con numerosas experiencias en cargas de trabajo de Microsoft, entornos híbridos y formación técnica para clientes como Technical Trainer y Evangelista. Ahora actúa como arquitecto de soluciones y combina todas las capacidades para reducir la burocracia y adoptar las mejores tecnologías a fin de ayudar a los clientes a superar sus desafíos diarios.

 

 

 

 

Juan Pablo Melgarejo Zamora es un arquitecto de soluciones especializado en Microsoft Workloads. Tiene experiencia en Software, DevOps y seguridad. Fuera del trabajo, le gusta viajar y cocinar.