Diseño de infraestructura

Extensión de AWS a entornos on-premises con AWS Outposts - Diseño y operación de nube híbrida

Extiende AWS a entornos on-premises para cumplir con requisitos de residencia de datos y baja latencia. Presentamos los modelos de despliegue de Outposts y el diseño del gateway local.

約 8 分で読めます

Casos de uso de Outposts

Outposts es un servicio que instala físicamente la infraestructura de AWS en centros de datos on-premises. Existen tres casos de uso principales. El primero es el requisito de residencia de datos. Cuando las regulaciones financieras o gubernamentales exigen mantener los datos dentro de un país o instalación específica, Outposts permite mantener los datos on-premises mientras se utilizan los servicios de AWS. El segundo es el requisito de baja latencia. Es eficaz cuando la latencia de ida y vuelta al cloud no es aceptable para el control de líneas de fabricación o el procesamiento de datos en tiempo real. El tercero es el procesamiento local de datos. Se utiliza cuando se genera una gran cantidad de datos en el entorno y se necesita preprocesarlos localmente antes de transferirlos al cloud. Ejemplos concretos por industria incluyen IoT industrial que analiza datos de sensores de equipos de fábrica en tiempo real, instituciones médicas que procesan imágenes de MRI y tomografía computarizada dentro de sus instalaciones, y sistemas de trading de instituciones financieras que requieren procesamiento de transacciones de baja latencia.

Servicios disponibles y diseño de red

Los servicios de AWS disponibles en Outposts incluyen EC2, EBS, S3 (S3 en Outposts), RDS, ECS, EKS, EMR y ElastiCache, entre otros. Estos servicios se operan con la misma API que AWS en la región y se pueden aprovisionar con CloudFormation o Terraform. La red se comunica con AWS en la región a través de la conexión de enlace de servicio y con la red on-premises a través del gateway local (LGW). El enlace de servicio se utiliza para el tráfico de gestión de Outposts (comunicación del plano de control, envío de métricas, actualizaciones de software) y acceso a servicios regionales, recomendándose un ancho de banda mínimo de 1 Gbps. El LGW se controla mediante entradas de tabla de rutas en las subredes de la VPC, configurando el enrutamiento hacia las VLAN on-premises. Usando pools de direcciones IP de propiedad del cliente (CoIP), se pueden asignar direcciones del espacio de direcciones on-premises directamente a las instancias en Outposts, evitando cambios en las reglas de firewall y controles de acceso existentes. Como se configura extendiendo las subredes de la VPC a Outposts, la integración con el diseño de VPC existente es sencilla.

Modelo operativo y costos

En los racks de Outposts, AWS se encarga de la instalación, mantenimiento, reemplazo de hardware y aplicación de parches de software. El cliente proporciona la energía eléctrica, refrigeración, seguridad física y conectividad de red del centro de datos. La tarificación es una suscripción de 3 años con tres opciones de pago: pago total anticipado, pago parcial anticipado y sin pago anticipado. No se generan cargos adicionales por instancias EC2 o volúmenes EBS, ya que la capacidad de cómputo y almacenamiento está incluida en la tarifa de suscripción. La implementación de Outposts requiere un plazo de entrega de varias semanas, siendo importante la verificación previa de los requisitos de energía, refrigeración y red del sitio. Los requisitos de energía del rack son aproximadamente 5-15 kVA según la configuración, y la refrigeración debe soportar el diseño estándar de ingesta frontal y escape trasero. Se debe asegurar el espacio físico para un rack de 42U, verificando previamente el ancho del camino de entrega y la capacidad de carga del piso. Puede encontrar información más detallada sobre Outposts en libros relacionados en Amazon.

Elección entre Outposts y Local Zones

Tanto Outposts como Local Zones proporcionan computación en el borde, pero sus modelos operativos difieren fundamentalmente. Las Local Zones son centros de datos a pequeña escala operados por AWS, con la infraestructura en instalaciones de AWS y no del cliente. Son adecuadas para cargas de trabajo que necesitan reducir la latencia pero no requieren que los datos permanezcan dentro de una instalación (servidores de juegos, codificación de video, servidores API cerca de los usuarios finales). En contraste, Outposts se instala físicamente en el centro de datos del cliente, garantizando que los datos nunca abandonen las instalaciones. El criterio más importante es si existen regulaciones de residencia de datos. Si las regulaciones exigen que los datos se mantengan dentro de una instalación, Outposts es la única opción. Si solo la latencia es un problema sin requisitos regulatorios, Local Zones ofrece un despliegue más simple sin inversión inicial. Wavelength Zones es una opción adicional colocada dentro de estaciones base de operadores, especializada en ultra-baja latencia en redes 5G.

Consideraciones de diseño e impacto de la desconexión del enlace de servicio

La consideración de diseño más importante para Outposts es el comportamiento cuando la conexión a la Región (enlace de servicio) se interrumpe. Durante una desconexión del enlace de servicio, las instancias en ejecución local y la comunicación a través del gateway local continúan, pero no se pueden ejecutar operaciones de lanzamiento/detención de nuevas instancias ni operaciones del plano de control (llamadas API). Esto significa que las cargas de trabajo se mantienen durante la desconexión, pero las operaciones de escalado y recuperación se vuelven imposibles. Dado esto, para cargas de trabajo críticas se debe pre-aprovisionar capacidad suficiente y considerar configuraciones estáticas que no dependan de Auto Scaling. Los datos de S3 en Outposts se retienen localmente y permanecen accesibles durante la desconexión del enlace, pero las operaciones del plano de control de S3 (creación de buckets, cambios de políticas) no se pueden ejecutar. Además, la capacidad de Outposts no puede expandirse elásticamente como la Región, por lo que el dimensionamiento debe considerar la demanda pico de la carga de trabajo. Si la capacidad resulta insuficiente, la adquisición de racks adicionales incurre en otro plazo de entrega.

Resumen

Outposts es un servicio que extiende la infraestructura de AWS a entornos on-premises, logrando un entorno híbrido con el mismo modelo operativo que el cloud. Ejecuta servicios de AWS como EC2, EBS, S3, RDS y ECS on-premises, operándolos con la misma API y herramientas de gestión que la región. Mantiene la experiencia de desarrollo cloud-native mientras cumple con los requisitos de residencia de datos y ultra baja latencia. Comprender la diferencia con Local Zones, el impacto de la desconexión del enlace de servicio y planificar la capacidad con anticipación son las claves para un despliegue exitoso.

Servicios relacionados

AWS OutpostsServicio de nube híbrida que extiende la infraestructura y servicios de AWS a ubicaciones on-premisesAmazon EC2Un servicio de cómputo que proporciona servidores virtuales en la nubeAmazon S3Servicio de almacenamiento de objetos escalable

Artículos relacionados

Operación de nube híbrida con Amazon EVS - Construcción de sitio DR y respuesta a ráfagasExplicamos la operación de nube híbrida con Amazon EVS. Presentamos la construcción de sitios DR, ráfagas de capacidad bajo demanda y patrones de integración con servicios de AWS.Entrenamiento de machine learning basado en GPU con AWS Batch - Entrenamiento a gran escala con eficiencia de costosEjecute entrenamiento GPU con sus contenedores Docker existentes y reduzca costos hasta un 90% usando instancias Spot y checkpointing. Incluye orientación sobre cuándo elegir Batch sobre SageMaker.Diseño y operación de volúmenes Amazon EBS - Criterios de selección gp3/io2 y estrategia de snapshotsClarificamos los criterios de selección de tipos de volumen gp3 e io2, y presentamos de forma práctica las directrices de diseño de IOPS y throughput, así como la estrategia de backup mediante snapshots.

Más sobre este tema

Por qué Auto Scaling escala rápido hacia afuera y es cauteloso al reducir - Intención de diseño de la lógica de decisión asimétricaExplica la razón del diseño asimétrico de EC2 Auto Scaling que ejecuta el scale-out inmediatamente mientras establece un período de enfriamiento para el scale-in, el mecanismo de prevención de flapping y la lógica interna del Target Tracking Scaling.Infraestructura adaptable a la demanda con AWS Auto Scaling - Diseño y optimización de políticas de escaladoPresenta cómo utilizar los 3 tipos de políticas (Target Tracking, Predictive y Scheduled) y lograr la optimización de costos con instancias Spot mediante Mixed Instances Policy.Diseño de dominios de fallo en AWS - El mecanismo de disponibilidad protegido por la estructura de 3 capas AZ, región y particiónExplicamos por qué la infraestructura de AWS está diseñada en 3 capas: AZ (aislamiento de fallos), región (separación geográfica) y partición (separación política), y hasta dónde se propagan los fallos en cada capa con ejemplos concretos.Principios de sistemas distribuidos aprendidos de las interrupciones de AWS - Arquitecturas transformadas por grandes incidentesUsando como material los informes de incidentes publicados por AWS, como la interrupción de S3 (2017), la interrupción de Kinesis (2020) y la particularidad de us-east-1, explicamos principios de diseño como Shuffle Sharding, Static Stability y Cell-based Architecture.Por qué AWS construye regiones allí - Los criterios desconocidos de selección de ubicación de centros de datosExplicamos los criterios de decisión que AWS considera al determinar la ubicación de regiones, como suministro eléctrico, riesgo geopolítico, legislación de soberanía de datos, conectividad de red y riesgo de desastres naturales, con ejemplos concretos de regiones.Por qué los Availability Zone ID de AWS difieren por cuenta - La intención de diseño detrás del mapeo de AZExplicamos cómo us-east-1a apunta a diferentes AZ físicas por cuenta, por qué se introdujeron los AZ ID (use1-az1), la intención de diseño de distribución uniforme de capacidad y las consideraciones para la especificación de AZ entre cuentas.Infraestructura de computación por lotes - Procesamiento paralelo a gran escala con AWS BatchExplicamos cómo construir procesamiento por lotes a gran escala con AWS Batch. Cubrimos el diseño de colas de trabajos, auto-escalado de entornos de cómputo, optimización de costos con instancias Spot y la construcción de infraestructura de lotes ideal para computación científica y procesamiento de datos a gran escala.Streaming en vivo con calidad broadcast - Construcción de plataforma de distribución a gran escala con AWS Elemental MediaLive y MediaPackageExplicamos cómo construir una plataforma de streaming en vivo con calidad broadcast usando AWS Elemental MediaLive y MediaPackage. Cubrimos transcodificación en tiempo real, DRM, inserción de anuncios y distribución multi-CDN.

Artículos y servicios similares

Nube híbrida con AWS Outposts - Extensión de servicios AWS al entorno on-premisesExplicación de la nube híbrida con AWS Outposts. Se presenta la extensión de servicios AWS al on-premises, los casos de uso de baja latencia y residencia de datos, y la integración con la región AWS.AWS OutpostsServicio de nube híbrida que instala físicamente la infraestructura y servicios de AWS en centros de datos on-premises, operándolos con las mismas APIs y herramientas que la nubeInfraestructura de nube híbrida - Integración de on-premises y AWS con AWS OutpostsAprende a extender la infraestructura de AWS a entornos on-premises con AWS Outposts y construir arquitecturas de nube híbrida con integración EC2. Cubre patrones de diseño para requisitos de residencia de datos y baja latencia.Estrategia de borde de AWS - El futuro híbrido que dibujan Outposts, Local Zones y WavelengthExplicamos la estrategia híbrida y de borde que AWS despliega a través de tres servicios de borde: Outposts, Local Zones y Wavelength, comparándolos con Azure Stack y GCP Distributed Cloud para destacar las diferencias en amplitud de opciones y filosofía de diseño.