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.
# Modos de error más extensos
Para diseñar arquitecturas de alta disponibilidad que mitiguen los modos de error más extensos, como errores de bastidor, de centro de datos, de zonas de disponibilidad (AZ) o de regiones, es necesario implementar varias instancias de Outposts con suficiente capacidad de infraestructura en centros de datos separados con conectividad WAN y alimentación independientes. Anclas los Outposts a diferentes zonas de disponibilidad (AZs) dentro de una Región de AWS o entre varias regiones. También debe proporcionar una site-to-site conectividad flexible y suficiente entre las ubicaciones para admitir la replicación de datos sincrónica o asincrónica y la redirección del tráfico de la carga de trabajo. Según la arquitectura de tu aplicación, puedes usar Amazon Route [53 DNS y Amazon Route 53](https://aws.amazon.com/route53/) [en Outposts, disponibles en](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/outpost-resolver.html) todo el mundo, para dirigir el tráfico a la ubicación deseada y automatizar el redireccionamiento del tráfico a las ubicaciones supervivientes en caso de que se produzcan errores a gran escala.
# Enrutamiento dentro de la VPC de Outposts Rack
AWS Outposts rack admite la [comunicación dentro de la VPC a través de varios Outposts](https://aws.amazon.com/blogs/compute/introducing-intra-vpc-communication-across-multiple-outposts-with-direct-vpc-routing/). Los recursos de dos Outposts lógicos separados pueden comunicarse entre sí mediante el enrutamiento del tráfico entre subredes dentro de la misma VPC que las atraviesa mediante las puertas de enlace locales (LGW) de Outpost. Con la comunicación dentro de la VPC entre varios Outposts, puedes anular la ruta local en la tabla de rutas asociada a la subred de Outposts añadiendo una ruta más específica a la otra subred de Outposts utilizando la LGW local como siguiente salto. [Puede ofrecer ventajas a la hora de diseñar aplicaciones que requieren extender una VPC entre dos Outposts lógicos, como [Amazon ECS en dos racks de Outposts o un clúster de Amazon EKS entre sí](https://community.aws/content/2k5wK9P1oSC9I4ZzuSLWynsiJaa/extend-amazon-ecs-across-two-outposts-racks). AWS Outposts](https://aws.amazon.com/blogs/containers/deploy-an-amazon-eks-cluster-across-aws-outposts-with-intra-vpc-communication/)
![\[Diagrama que muestra las rutas de red para una sola VPC con varios Outposts lógicos\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/page-49-single-vpc-multiple-outposts.png)
Outposts-to-Outposts El enrutamiento del tráfico a través de la región está bloqueado, ya que no es un patrón. Este tráfico generaría gastos de salida en ambas direcciones y una latencia significativamente mayor que si se enrutara el tráfico a través de la WAN del cliente.
# Enrutamiento entre VPC de Outposts Rack
Los recursos de dos Outposts separados desplegados en lugares diferentes VPCs pueden comunicarse entre sí a través de la red del cliente. La implementación de esta arquitectura le permite enrutar el tráfico a Outposts-to-Outposts través de sus redes locales locales y WAN, agregando rutas hacia las subredes de VPC o Outpost homólogas.
![\[Diagrama que muestra las rutas de red para múltiples VPC con múltiples Outposts lógicos\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/page-50-multiple-vpc-multiple-outposts-networking-path.png)
Prácticas recomendadas para protegerse frente a modos de error más extensos
+ Despliega varios Outposts anclados en múltiples AZs regiones.
+ Utilízalo VPCs por separado para cada puesto de avanzada en un despliegue de varios puestos de avanzada.
# Route 53 Local Resolver en Outposts
Cuando el enlace del AWS Outposts servicio se ve afectado por una desconexión temporal, la resolución del DNS local falla, lo que dificulta que las aplicaciones y los servicios descubran otros servicios, incluso cuando se ejecutan en el mismo rack de Outposts. Sin embargo, con Route 53 Resolver activado AWS Outposts, las aplicaciones y los servicios seguirán beneficiándose de la resolución de DNS local para detectar otros servicios, incluso en el caso de que el principal pierda la conectividad Región de AWS. Al mismo tiempo, para la resolución de DNS para nombres de host locales, el Route 53 Resolver de Outposts ayuda a reducir la latencia, ya que los resultados de las consultas se almacenan en caché y se sirven localmente, a la vez que se integra completamente con los puntos finales de Route 53 Resolver.
Los puntos finales entrantes del solucionador de Route 53 reenvían las consultas de DNS que reciben desde fuera de la VPC al solucionador que se ejecuta en Outposts. Por el contrario, Route 53 Resolver Outbound permite a los Resolvers de Route 53 reenviar consultas de DNS a los solucionadores de DNS que usted administra en la red local, como se ilustra en el siguiente diagrama.
![\[Diagrama que muestra el solucionador Route 53 en Outposts\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/page-51-route53-resolver-outposts.png)
## Consideraciones sobre Route 53 Resolver on Outposts
Considere lo siguiente:
+ Debes habilitar el Solucionador de Route 53 en Outposts y se aplica a todo el despliegue de Outposts, incluso si se trata de varios racks de cómputo con un único ID de Outposts.
+ Para habilitar esta función, tus Outposts deben tener suficiente capacidad de cómputo para implementar el solucionador local en forma de al menos 4 EC2 instancias de cualquier c5.xlarge, m5.large o m5.xlarge.
+ Si utiliza un DNS privado, debe compartir la zona alojada privada con los Outposts VPCs necesarios para almacenar en caché los registros de forma local en el Route 53 Resolver de Outposts.
+ Para permitir la integración con el DNS local con los puntos de conexión entrantes y salientes, sus Outposts deben tener suficiente capacidad de procesamiento para implementar dos instancias por cada punto de conexión de Route53. EC2
# Clúster local de EKS en Outposts
Cuando se produce una desconexión del enlace del servicio de Outposts desde la región matriz, es posible que surjan problemas con servicios como el EKS Extended Cluster, donde el plano de control se encuentra en la región. Entre los desafíos está la pérdida de comunicación entre el plano de control del EKS y los nodos trabajadores y. PODs Aunque ambos nodos de trabajo PODs pueden seguir funcionando y dando servicio a las aplicaciones que residen en Outposts de forma local, el plano de control de Kubernetes puede considerarlas insalubres y programar su reemplazo cuando se recupere la conexión con el plano de control. Esto puede provocar tiempos de inactividad de las aplicaciones cuando se restablezca la conectividad.
Para simplificar esto, existe la opción de alojar todo tu clúster de EKS en Outposts. En esta configuración, tanto el plano de control de Kubernetes como los nodos de trabajo se ejecutan localmente en las instalaciones de la capacidad de cómputo de Outposts. De esta forma, el clúster seguirá funcionando incluso en caso de que se interrumpa temporalmente la conexión del enlace de servicio y después de que se restablezca.
![\[Clúster local de Amazon EKS en Outposts\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/page-52-eks-local-cluster-outposts.png)
## Consideraciones sobre el Clúster Local de EKS en Outposts
Hay algunas consideraciones a tener en cuenta a la hora de implementar un clúster local de EKS en Outposts:
+ Durante una desconexión, no hay opciones para ejecutar ningún cambio en el propio clúster que requiera agregar nuevos nodos de trabajo o escalar automáticamente un grupo de nodos, siempre que EC2 dependa de las llamadas de la API de ASG a la AWS región principal.
+ [• Hay un conjunto de funciones no compatibles en los clústeres locales que figuran en la lista de compatibilidad con eksctl. AWS Outposts](https://eksctl.io/usage/outposts/) .