

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.

# infraestructura de AWS
<a name="aws-infrastructure"></a>

 En esta sección se presenta un resumen de la infraestructura AWS global y de los límites de aislamiento de fallas que proporciona. Además, en esta sección se proporcionará una visión general del concepto de planos de control y planos de datos, que son distinciones fundamentales a la hora de AWS diseñar sus servicios. Esta información proporciona la base para comprender cómo se aplican los límites de aislamiento de fallas y el plano de control y el plano de datos de un servicio a los tipos de AWS servicio que analizamos en la siguiente sección. 

**Topics**
+ [Zonas de disponibilidad](availability-zones.md)
+ [Regiones](regions.md)
+ [AWSZonas Locales](aws-local-zones.md)
+ [AWS Outposts](aws-outposts.md)
+ [Puntos de presencia](points-of-presence.md)
+ [Particiones](partitions.md)
+ [Planos de control y planos de datos](control-planes-and-data-planes.md)
+ [Estabilidad estática](static-stability.md)
+ [Resumen](summary.md)

# Zonas de disponibilidad
<a name="availability-zones"></a>

 AWSopera más de 100 zonas de disponibilidad en varias regiones del mundo (las cifras actuales se encuentran aquí: [Infraestructura AWS global](https://aws.amazon.com/about-aws/global-infrastructure/)). Una zona de disponibilidad es uno o más centros de datos discretos con una infraestructura de alimentación, redes y conectividad independientes y redundantes en unRegión de AWS. Las zonas de disponibilidad de una región están significativamente distantes entre sí, hasta 60 millas (\$1100 km) para evitar fallos correlacionados, pero lo suficientemente cerca como para utilizar la replicación sincrónica con una latencia de milisegundos de un solo dígito. Están diseñadas para no verse afectadas simultáneamente por un escenario de destino compartido, como el suministro eléctrico, las interrupciones del suministro de agua, el aislamiento de la fibra, los terremotos, los incendios, los tornados o las inundaciones. Los puntos de fallo más comunes, como los generadores y los equipos de refrigeración, no se comparten entre las distintas zonas de disponibilidad y están diseñados para ser alimentados por subestaciones eléctricas independientes. Cuando AWS implementa actualizaciones de sus servicios, las implementaciones en las zonas de disponibilidad de la misma región se separan en el tiempo para evitar fallos correlacionados. 

 Todas las zonas de disponibilidad de una región están interconectadas con redes de gran ancho de banda y baja latencia, a través de fibra metropolitana dedicada y totalmente redundante. Cada zona de disponibilidad de una región se conecta a Internet a través de dos centros de tránsito que AWS coinciden con varios [proveedores de Internet de nivel 1](https://en.wikipedia.org/wiki/Tier_1_network) (para obtener más información, consulte [Descripción general de Amazon Web Services](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html?did=wp_card&trk=wp_card)*)*. 

 Estas características proporcionan un fuerte aislamiento entre las zonas de disponibilidad, lo que denominamos independencia de la zona de disponibilidad (AZI). La estructura lógica de las zonas de disponibilidad y su conectividad a Internet se muestra en la siguiente figura. 

![\[Esta imagen muestra cómo las zonas de disponibilidad constan de uno o más centros de datos físicos que están conectados de forma redundante entre sí y a Internet\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-fault-isolation-boundaries/images/availability-zones.png)


# Regiones
<a name="regions"></a>

 Cada una Región de AWS consta de varias zonas de disponibilidad independientes y físicamente separadas dentro de un área geográfica. Actualmente, todas las regiones tienen tres o más zonas de disponibilidad. Las propias regiones están aisladas y son independientes de otras regiones, con algunas excepciones que se indican más adelante en este documento [(consulte la sección Operaciones globales de una sola región)](global-services.md#global-single-region-operations). Esta separación entre regiones limita los fallos de servicio, cuando se producen, a una sola región. En este caso, las operaciones normales de otras regiones no se ven afectadas. Además, los recursos y los datos que cree en una región no existen en ninguna otra, a menos que utilice explícitamente una función de replicación o copia ofrecida por un AWS servicio o replique el recurso usted mismo. 

![\[Esta imagen ilustra las regiones de AWS actuales y planificadas a diciembre de 2022.\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-fault-isolation-boundaries/images/current-and-planned-aws-regions.png)


# AWSZonas Locales
<a name="aws-local-zones"></a>

 AWSLas [Zonas Locales](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) son un tipo de implementación de infraestructura que coloca la computación, el almacenamiento, las bases de datos y otros [AWSservicios selectos](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/) cerca de grandes centros industriales y de población. Puede usar AWS servicios, como los servicios de cómputo y almacenamiento, en la zona local para ejecutar aplicaciones de baja latencia en la periferia o simplificar las migraciones a la nube híbrida. Las Zonas Locales tienen acceso y salida de Internet local para reducir la latencia, pero también están conectadas a su región principal a través de la red privada redundante y de gran ancho de banda de Amazon, lo que proporciona a las aplicaciones que se ejecutan en las zonas AWS locales un acceso rápido, seguro y sin problemas a toda la gama de servicios. 

# AWS Outposts
<a name="aws-outposts"></a>

 [AWS Outposts](https://aws.amazon.com/outposts/)es una familia de soluciones totalmente gestionadas que ofrecen AWS infraestructura y servicios a prácticamente cualquier ubicación local o perimetral para ofrecer una experiencia híbrida realmente coherente. Las soluciones de Outposts le permiten ampliar y ejecutar los AWS servicios nativos de forma local, y están disponibles en una variedad de formatos, desde servidores Outposts de 1U y 2U hasta racks Outposts de 42U y despliegues de múltiples racks. 

 Con élAWS Outposts, puede ejecutar [determinados AWS servicios de forma local y conectarse a una amplia gama de servicios](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html#services) disponibles en el servidor principal. Región de AWS AWS Outpostsson racks de cómputo y almacenamiento totalmente gestionados y configurables, construidos con hardware AWS diseñado que permite a los clientes ejecutar el procesamiento y el almacenamiento en sus instalaciones, a la vez que se conectan sin problemas a AWS la amplia gama de servicios en la nube. 

# Puntos de presencia
<a name="points-of-presence"></a>

 Además de las zonas de disponibilidad Regiones de AWS y disponibilidad, AWS también opera una red de puntos de presencia (PoP) distribuidos a nivel mundial. Estos PoPs alojan Amazon CloudFront, una red de entrega de contenido (CDN); Amazon Route 53, un servicio de resolución del Sistema de Nombres de Dominio (DNS) público; y AWS Global Accelerator (AGA), un servicio de optimización de redes periféricas. La red perimetral global consta actualmente de más de 410 PoPs, incluidas más de 400 ubicaciones perimetrales y 13 cachés regionales de nivel medio en más de 90 ciudades de 48 países (el estado actual puede consultarse aquí: [Amazon CloudFront Key Features](https://aws.amazon.com/cloudfront/features/)). 

![\[Esta imagen muestra la red perimetral CloudFront global de Amazon\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-fault-isolation-boundaries/images/amazon-cloudfront.png)


 Cada PoP está aislado de los demás, lo que significa que una falla que afecte a una sola PoP o área metropolitana no afectará al resto de la red global. La AWS red es similar a la de miles de operadores de telecomunicaciones de nivel 1/2/3 en todo el mundo, está bien conectada con las principales redes de acceso para ofrecer un rendimiento óptimo y tiene una capacidad desplegada de cientos de terabits. Las ubicaciones periféricas se conectan a Regiones de AWS través de la AWS red troncal, una fibra paralela múltiple de 100 GbE totalmente redundante que rodea el mundo y se conecta con decenas de miles de redes para mejorar las búsquedas de origen y acelerar el contenido dinámico. 

# Particiones
<a name="partitions"></a>

 AWS[agrupa las regiones en particiones.](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) Cada región está exactamente en una partición y cada partición tiene una o más regiones. Las particiones tienen instancias independientes de AWS Identity and Access Management (IAM) y proporcionan un límite estricto entre las regiones de las distintas particiones. AWSLas regiones comerciales están en la `aws` partición, las regiones de China están en la `aws-cn` partición y AWS GovCloud las regiones están en la `aws-us-gov` partición. Algunos AWS servicios están diseñados para ofrecer funcionalidad entre regiones, como la [replicación entre regiones de Amazon S3 o la interconexión entre regiones](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html#crr-scenario) de [AWSTransit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html). Estos tipos de capacidades solo se admiten entre regiones de la misma partición. No puede usar las credenciales de IAM de una partición para interactuar con los recursos de otra partición. 

# Planos de control y planos de datos
<a name="control-planes-and-data-planes"></a>

 AWSsepara la mayoría de los servicios en los conceptos de plano de *control y plano* *de datos.* Estos términos provienen del mundo de las redes, específicamente de los enrutadores. El plano de datos del router, que es su principal funcionalidad, consiste en mover los paquetes según reglas. Pero las políticas de enrutamiento deben crearse y distribuirse desde algún lugar, y ahí es donde entra en juego el plano de control. 

 Los planos de control proporcionan las API administrativas que se utilizan para crear, leer/describir, actualizar, eliminar y enumerar los recursos (CRUDL). Por ejemplo, todas las acciones del plano de control son las siguientes: lanzar una nueva instancia de [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2), crear un bucket de [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) y describir una cola de [Amazon Simple Queue Service](https://aws.amazon.com/sqs/) (Amazon SQS). Al lanzar una instancia EC2, el plano de control debe realizar varias tareas, como encontrar un host físico con capacidad, asignar las interfaces de red, preparar un volumen de Amazon [Elastic Block Store (Amazon](https://aws.amazon.com/ebs/) EBS), generar credenciales de IAM, añadir las reglas del grupo de seguridad y mucho más. Los planos de control suelen ser sistemas complicados de organización y agregación. 

 El plano de datos es lo que proporciona la función principal del servicio. Por ejemplo, las siguientes son todas las partes del plano de datos de cada uno de los servicios involucrados: la propia instancia de EC2 en ejecución, la lectura y escritura en un volumen de EBS, la obtención y colocación de objetos en un depósito de S3 y la respuesta de Route 53 a las consultas de DNS y a la realización de comprobaciones de estado. 

 Los planos de datos son intencionalmente menos complicados y tienen menos partes móviles en comparación con los planos de control, que suelen implementar un sistema complejo de flujos de trabajo, lógica empresarial y bases de datos. Esto hace que, desde el punto de vista estadístico, sea menos probable que se produzcan eventos de falla en el plano de datos que en el plano de control. Si bien tanto el plano de datos como el de control contribuyen al funcionamiento general y al éxito del servicio, los AWS considera componentes distintos. Esta separación tiene beneficios tanto en términos de rendimiento como de disponibilidad. 

# Estabilidad estática
<a name="static-stability"></a>

 Una de las características de resiliencia más importantes de los AWS servicios es lo que se AWS denomina estabilidad estática. Lo que este término significa es que los sistemas funcionan en un estado estático y siguen funcionando con normalidad sin necesidad de realizar cambios durante el fallo o la falta de disponibilidad de las dependencias. Una forma de hacerlo es evitar las dependencias circulares en nuestros servicios que podrían impedir que uno de esos servicios se recupere correctamente. Otra forma de hacerlo es manteniendo el estado actual. Consideramos el hecho de que los planos de control tienen estadísticamente más probabilidades de fallar que los planos de datos. Si bien el plano de datos suele depender de los datos que llegan desde el plano de control, el plano de datos mantiene su estado actual y sigue funcionando incluso cuando el plano de control está dañado. El acceso a los recursos del plano de datos, una vez aprovisionado, no depende del plano de control y, por lo tanto, no se ve afectado por ninguna alteración del plano de control. En otras palabras, incluso si la capacidad de crear, modificar o eliminar recursos se ve afectada, los recursos existentes permanecen disponibles. Esto hace que AWS los planos de datos se mantengan estáticamente estables ante una alteración en el plano de control. Puede implementar diferentes patrones para mantener una estabilidad estática frente a diferentes tipos de fallas de dependencia. 

 Puede encontrar un ejemplo de estabilidad estática en Amazon EC2. Una vez que se ha lanzado una instancia de EC2, está tan disponible como el servidor físico de un centro de datos. No depende de ninguna API del plano de control para seguir funcionando o volver a funcionar tras un reinicio. La misma propiedad se aplica a otros AWS recursos, como las VPC, los buckets y objetos de Amazon S3 y los volúmenes de Amazon EBS. 

 La estabilidad estática es un concepto que está profundamente arraigado en la forma en que AWS diseña sus servicios, pero también es un patrón que pueden utilizar los clientes. De hecho, la mayoría de las recomendaciones sobre mejores prácticas para utilizar los diferentes tipos de AWS servicios de forma resiliente consisten en implementar la estabilidad estática en los entornos de producción. Los mecanismos de recuperación y mitigación más confiables son los que requieren menos cambios para lograr la recuperación. En lugar de confiar en el plano de control de EC2 para lanzar nuevas instancias de EC2 para recuperarse de una zona de disponibilidad fallida, disponer de esa capacidad adicional previamente aprovisionada ayuda a lograr la estabilidad estática. Por lo tanto, eliminar las dependencias de los planos de control (las API que implementan los cambios en los recursos) de su ruta de recuperación ayuda a generar cargas de trabajo más resilientes. Para obtener más información sobre la estabilidad estática, los planos de control y los planos de datos, consulte el artículo [Static Stability using Availability Zones de Amazon Builders Library.](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 

# Resumen
<a name="summary"></a>

 AWSutiliza diferentes contenedores de fallas en nuestra infraestructura para aislar las fallas. Los principales contenedores de fallas de la infraestructura son las particiones, las regiones, las zonas de disponibilidad, los planos de control y los planos de datos. A continuación, examinaremos los diferentes tipos de AWS servicios, cómo se utilizan estos contenedores de fallas en su diseño y cómo se deben diseñar las cargas de trabajo con ellos para que sean resilientes. 