Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Zonas de disponibilidad

Una zona de disponibilidad (AZ) consiste en uno o varios centros de datos discretos con alimentación, networking y conectividad redundantes en una Región de AWS. Las zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las infraestructuras tradicionales de centros de datos únicos o múltiples.

Amazon WorkSpaces Applications solo requiere una subred para lanzar una flota. Se recomienda configurar un mínimo de dos zonas de disponibilidad, una subred por cada zona de disponibilidad única. Para optimizar el escalado automático de la flota, utilice más de dos zonas de disponibilidad. El escalado horizontal tiene la ventaja adicional de añadir espacio IP en las subredes para facilitar el crecimiento, algo que se explica en la siguiente sección de este documento que trata sobre el tamaño de las subredes. La consola de administración de AWS permite especificar solo dos subredes durante la creación de una flota. Utilice la AWS Command Line Interface(AWS CLI) o AWS CloudFormation permita más de dos ID de subred.

Tamaño de subred

Dedique las subredes a WorkSpaces las flotas de aplicaciones para permitir la flexibilidad de las políticas de enrutamiento y a la lista de control de acceso a la red. Es probable que las pilas tengan requisitos de recursos independientes. Por ejemplo, WorkSpaces las pilas de aplicaciones pueden tener requisitos de aislamiento y dar paso a conjuntos de reglas independientes. Cuando varias flotas de Amazon WorkSpaces Applications utilicen las mismas subredes, asegúrese de que la suma de la capacidad máxima de todas las flotas no supere el número total de direcciones IP disponibles.

Si la capacidad máxima de todas las flotas de la misma subred pudiese superar o ha superado el número total de direcciones IP disponibles, migre las flotas a subredes dedicadas. Esto evita que los eventos de escalado automático agoten el espacio IP asignado. Si la capacidad total de una flota supera el espacio IP asignado a las subredes asignadas, utilice la API o la AWS CLI «actualizar flota» para asignar más subredes. Para obtener más información, consulte las cuotas de Amazon VPC y cómo aumentarlas.

Se recomienda escalar horizontalmente la cantidad de subredes y dimensionarlas en consecuencia y, al mismo tiempo, reservar capacidad para crecer en la VPC. Además, asegúrese de que los máximos de la flota de WorkSpaces aplicaciones no superen el espacio IP total asignado por las subredes. Para cada entrada de subred AWS, se reservan cinco direcciones IP al calcular la cantidad total de espacio IP. El uso de más de dos subredes y el escalado horizontal ofrecen varias ventajas, por ejemplo:

Al dimensionar las subredes para Amazon WorkSpaces Applications, tenga en cuenta el número total de subredes y el pico de simultaneidad esperado durante los picos de uso. Esto se puede monitorear usando (InUseCapacity) además de la capacidad reservada (AvailableCapacity) para una flota. En Amazon WorkSpaces Applications, se etiqueta la suma de las instancias de la flota de aplicaciones consumidas y disponibles WorkSpaces para su consumo. ActualCapacity Para dimensionar correctamente el espacio total IP, haga una previsión del ActualCapacity necesario y divídalo por el número de subredes asignadas a la flota, menos una subred por motivos de resiliencia.

Por ejemplo, si el número máximo previsto de instancias de flota en el momento máximo es de 1000 y el requisito empresarial es ser resiliente en caso de fallo en una zona de disponibilidad, tres x/23 subredes cumplen los requisitos técnicos y empresariales.

Ejemplo de dimensionamiento de subredes

Si bien 2 x /22 subredes también satisfacerían la resiliencia, tenga en cuenta lo siguiente:

Enrutar la subred

Se recomienda crear subredes privadas para WorkSpaces las instancias de aplicaciones, enrutándolas a la Internet pública a través de una VPC centralizada para el tráfico saliente. El tráfico entrante para la transmisión de sesiones de WorkSpaces Applications se gestiona a través del servicio Amazon WorkSpaces Applications a través de Streaming Gateways: no es necesario configurar subredes públicas para ello.

Intra-Region conectividad

Para WorkSpaces las instancias de la flota de aplicaciones unidas a un dominio de Active Directory, configure los controladores de dominio de Active Directory en una VPC de Shared Services en cada una de ellas. Región de AWS Las fuentes de Active Directory pueden ser controladores de dominio basados en Amazon EC2 o Microsoft Managed AD de AWS . El enrutamiento entre los servicios compartidos y WorkSpaces las VPC de aplicaciones puede realizarse a través de una conexión de emparejamiento de VPC o una puerta de enlace de tránsito. Si bien las puertas de enlace de tránsito resuelven la complejidad del enrutamiento a escala, existen varias razones por las que es preferible la interconexión de VPC en la mayoría de los entornos:

Esto es especialmente cierto si WorkSpaces las instancias de aplicaciones se conectan a servidores de and/or archivos de infraestructura de aplicaciones con grandes conjuntos de datos en una VPC de servicio compartido. Al optimizar la ruta a estos recursos de acceso común, se prefiere la conexión de emparejamiento de VPC, incluso en diseños en los que todos los demás enrutamientos de VPC e Internet se realizan a través de una puerta de enlace de tránsito.

Tráfico de internet saliente

Si bien el enrutamiento directo a los servicios compartidos se optimiza principalmente mediante una conexión entre pares, el tráfico saliente de WorkSpaces las aplicaciones se puede diseñar creando un único punto de salida de Internet desde varias VPC mediante Transit Gateway AWS . En un diseño de VPC múltiple, es una práctica estándar tener una VPC dedicada que controle todo el tráfico de internet saliente. Con esta configuración, las puertas de enlace de tránsito tienen mayor flexibilidad y control del enrutamiento a través de tablas de enrutamiento estándar conectadas a las subredes. Este diseño también es compatible con el enrutamiento transitivo sin complejidad adicional y elimina la necesidad de puertas de enlace de traducción de direcciones de red (NAT) redundantes o instancias de NAT en cada VPC.

Una vez que todo el tráfico de internet saliente esté centralizado en una VPC única, las puertas de enlace NAT o las instancias NAT suelen escogerse en el diseño. Para determinar cuál es la mejor opción para su organización, consulte la guía de administración para comparar las puertas de enlace NAT y las instancias de NAT. AWS Network Firewall puede extender la protección más allá de los niveles de control de acceso a la red y del grupo de seguridad, ya que protege a nivel de ruta y ofrece reglas sin estado y con estado desde las capas 3 a 7 del modelo OSI. Para obtener más información, consulte Modelos de implementación de AWS Network Firewall. Si su organización ha elegido un producto de terceros que ofrece características avanzadas, como el filtrado de URL, implemente el servicio en su VPC de internet saliente. Esto puede sustituir a las puertas de enlace de NAT o a las instancias de NAT. Siga las pautas proporcionadas por el proveedor externo.

On-premises

Cuando sea necesaria la conectividad con los recursos locales, especialmente en el caso de WorkSpaces las instancias de aplicaciones unidas a Active Directory, establezca una conexión a través AWS Direct Connect de la cual sea altamente resistente.