Compartir vía

Confiabilidad en Load Balancer

  • Artículo

Este artículo contiene recomendaciones específicas de fiabilidad para Load Balancer, además de información detallada sobre la resistencia regional de Load Balancer con zonas de disponibilidad, y recuperación ante desastres y continuidad empresarial entre regiones.

Para obtener información arquitectónica general sobre la fiabilidad de Azure, consulte Fiabilidad de Azure.

Recomendaciones sobre la confiabilidad

Esta sección contiene recomendaciones para lograr la resistencia y la disponibilidad. Cada recomendación se divide en una de las dos categorías:

  • Los elementos de mantenimiento abarcan áreas como los elementos de configuración y el funcionamiento correcto de los principales componentes que se encargan de su carga de trabajo de Azure, como la configuración de recursos de Azure, dependencias de otros servicios, etc.

  • Los elementos de riesgo abarcan áreas como los requisitos de disponibilidad y recuperación, pruebas, supervisión, implementación y otros elementos que, si se dejan sin resolver, aumentarán la probabilidad de que surjan problemas en el entorno.

Matriz de prioridad de recomendaciones de fiabilidad

Cada recomendación se marca según la siguiente matriz de prioridad:

Imagen Prioridad Descripción
Alto Se necesita corrección inmediata.
Media Corregir en un plazo de entre 3 y 6 meses.
Bajo Necesita revisión.

Resumen de recomendaciones de fiabilidad

Category Priority Recomendación
Disponibilidad Asegurarse de que Standard Load Balancer tiene redundancia de zonas
Asegúrese de que el grupo de back-end contiene al menos dos instancias
Eficacia del sistema Usar NAT Gateway en lugar de reglas de salida para cargas de trabajo de producción
Usar SKU de Standard Load Balancer

Disponibilidad

Asegurarse de que Standard Load Balancer tiene redundancia de zonas

En una región que admita zonas de disponibilidad, Standard Load Balancer debería implementarse con redundancia de zona. Un Load Balancer con redundancia de zona permite atender el tráfico mediante una única dirección IP de front-end que puede sobrevivir a errores de zona. Se puede usar la IP de front-end para llegar a todos los miembros del grupo de back-end (no afectados), independientemente de la zona. Si se produce un error en una zona de disponibilidad, la ruta de acceso a los datos puede sobrevivir siempre que las zonas restantes de la región permanezcan en buen estado. Para obtener más información, consulte equilibrador de carga con redundancia de zona.

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

Asegúrese de que el grupo de back-end contiene al menos dos instancias

Implemente Load Balancer con al menos dos instancias en el back-end. Una única instancia podría dar lugar a un único punto de error. Para compilar a escala, puede que quiera emparejar Load Balancer con Virtual Machine Scale Sets.

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

Eficacia del sistema

Usar NAT Gateway en lugar de reglas de salida para cargas de trabajo de producción

Las reglas de salida asigna cantidades fijas de puertos SNAT a cada instancia de máquina virtual de un grupo de back-end. Este método de asignación puede provocar el agotamiento de puertos SNAT, especialmente si los patrones de tráfico desiguales dan lugar a que una máquina virtual específica envíe un mayor volumen de conexiones salientes. En el caso de las cargas de trabajo de producción, se recomienda acoplar Standard Load Balancer o cualquier implementación de subred con Azure NAT Gateway. NAT Gateway asigna dinámicamente puertos SNAT en todas las instancias de máquina virtual de una subred y, a su vez, reduce el riesgo de agotamiento de puertos SNAT.

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

Usar SKU de Standard Load Balancer

La SKU estándar de Load Balancer admite zonas de disponibilidad y resistencia de zona, mientras que la SKU básica, no. Cuando una zona deja de funcionar, Standard Load Balancer con redundancia de zona no se verá afectado y las implementaciones pueden resistir errores de zona dentro de una región. Además, Standard Load Balancer admite el equilibrio de carga entre regiones, para garantizar que la aplicación no se vea afectada por los errores de región.

Nota:

Los equilibradores de carga básicos no tienen Acuerdo de Nivel de Servicio (SLA).

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

Compatibilidad de zonas de disponibilidad

Las zonas de disponibilidad de Azure son al menos tres grupos de centros de datos físicamente independientes dentro de cada región de Azure. Los centros de datos de cada zona están equipados con infraestructura de alimentación, refrigeración y red independientes. En el caso de un error en la zona local, las zonas de disponibilidad están diseñadas de manera que, si se ve afectada una zona, los servicios, la capacidad y la alta disponibilidad regionales serán proporcionadas por las dos zonas restantes.

Estos errores pueden abarcar desde errores de software y hardware hasta eventos como terremotos, inundaciones e incendios. La tolerancia a los errores se logra con la redundancia y el aislamiento lógico de los servicios de Azure. Para más información sobre las zonas de disponibilidad en Azure, consulte Regiones y zonas de disponibilidad.

Los servicios habilitados para zonas de disponibilidad de Azure están diseñados para proporcionar el nivel adecuado de confiabilidad y flexibilidad. Se pueden configurar de dos maneras. Pueden tener redundancia de zona, con una replicación automática entre zonas o ser zonales, con instancias ancladas a una zona específica. También puede combinar ambos enfoques. Para más información sobre la arquitectura zonal frente a la arquitectura con redundancia de zona, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.

Azure Load Balancer admite escenarios de zonas de disponibilidad. Puede usar Standard Load Balancer para aumentar la disponibilidad en todo el escenario mediante la alineación de recursos con zonas y su distribución entre ellas. Revise este documento para conocer estos conceptos y la guía de diseño de un escenario básico.

Aunque se recomienda implementar Load Balancer con redundancia de zona, Load Balancer puede tener redundancia de zona, ser zonal o no zonal. La selección de zona de disponibilidad del equilibrador de carga es sinónimo de la selección de zona de la dirección IP de front-end. En el caso de los equilibradores de carga públicos, si la dirección IP pública del front-end del equilibrador de carga es redundante de zona, el equilibrador de carga también tiene redundancia de zona. Si la dirección IP pública del front-end del equilibrador de carga es zonal, el equilibrador de carga también se designará en la misma zona. Para configurar las propiedades relacionadas con la zona para el equilibrador de carga, seleccione el tipo de front-end adecuado que sea necesario.

Nota:

No es necesario tener un equilibrador de carga para cada zona, sino tener un único equilibrador de carga con varios front-end (con redundancia de zona o zonal) asociados a sus respectivos grupos de back-end.

Requisitos previos

  • Para usar zonas de disponibilidad con Load Balancer, debe crear el equilibrador de carga en una región que admita zonas de disponibilidad. Para ver qué regiones admiten zonas de disponibilidad, consulte la lista de regiones admitidas.

  • Use la SKU estándar para el equilibrador de carga e IP pública para asistencia sobre zonas de disponibilidad.

  • No se admite el tipo de SKU básica.

  • Para crear el recurso, debe tener el rol Colaborador de red o superior.

Limitaciones

  • Las zonas no se pueden cambiar, actualizar ni crear para el recurso después de su creación.
  • Los recursos no se pueden actualizar de zonal a con redundancia de zona y viceversa después de su creación.

Equilibrador de carga con redundancia de zona

En una región con zonas de disponibilidad, un Standard Load Balancer podría tener redundancia de zona con tráfico servido por una sola dirección IP. Una única dirección IP de servidor front-end sobrevivirá a los errores de zona. Se puede usar la IP de front-end para llegar a todos los miembros del grupo de back-end (no afectados), independientemente de la zona. Hasta una zona de disponibilidad puede producir un error y la ruta de acceso a los datos sobrevive siempre que las zonas restantes de la región permanezcan en buen estado.

La dirección IP del front-end se suministra a la vez en varias implementaciones de infraestructura independientes de varias zonas de disponibilidad. Los reintentos o el restablecimiento se realizarán correctamente en otras zonas a las que no haya afectado por el error de zona.

La ilustración muestra un equilibrador de carga estándar con redundancia de zona que dirige el tráfico de tres zonas diferentes a tres subredes diferentes en una configuración con redundancia de zona.

Nota:

Las máquinas virtuales 1,2 y 3 pueden pertenecer a la misma subred y no tienen que estar necesariamente en zonas independientes como las sugerencias de diagrama.

Los miembros del grupo back-end de un equilibrador de carga normalmente se asocian con una única zona (por ejemplo, con máquinas virtuales zonales). Un diseño común para cargas de trabajo de producción sería tener varios recursos zonales. Por ejemplo, la colocación de máquinas virtuales de la zona 1, 2 y 3 en el back-end de un equilibrador de carga con un front-end con redundancia de zona cumple este principio de diseño.

Equilibrador de carga zonal

Puede optar por tener un front-end garantizado para una sola zona, lo que se conoce como zonal. En este escenario, una sola zona de una región atenderá todo el flujo entrante o saliente. El front-end comparte destino con el estado de la zona. La ruta de acceso de datos no se ve afectada por errores en zonas distintas a la garantizada. Puede utilizar front-end zonales para exponer una dirección IP por cada zona de disponibilidad.

Además, se admite el uso de servidores front-end zonales directamente para puntos de conexión con equilibrio de carga dentro de cada zona. Puede usar esta configuración para exponer puntos de conexión con equilibrio de carga por zona para supervisar de forma individual cada zona. En el caso de los puntos de conexión públicos, puede integrarlos con un producto de equilibrio de carga de DNS como Traffic Manager y usar un nombre DNS único.

La ilustración muestra tres equilibradores de carga estándar zonales que dirigen el tráfico de una zona a tres subredes diferentes de una configuración zonal.

En el caso de un servidor front-end de equilibrador de carga público, se agrega un parámetro de zonas a la dirección IP pública. La configuración IP del servidor front-end que usa la regla correspondiente hace referencia a esta dirección IP pública.

En el caso de un servidor front-end de equilibrador de carga interno, se agrega un parámetro de zonas a la configuración IP del front-end del recurso de equilibrador de carga interno. Un servidor front-end zonal garantiza una dirección IP en una subred a una zona específica.

Equilibrador de carga no zonal

Los equilibradores de carga también se pueden crear en una configuración no zonal mediante un front-end "sin zona". En estos escenarios, un equilibrador de carga público usaría una dirección IP pública o un prefijo de IP pública y un equilibrador de carga interno usaría una dirección IP privada. Esta opción no ofrece garantía de redundancia.

Nota

Todas las direcciones IP públicas que se actualicen de una SKU básica a otra estándar serán de tipo "sin zona". Aprenda a actualizar una dirección IP pública en Azure Portal.

Mejoras de SLA

Dado que las zonas de disponibilidad son físicamente independientes y proporcionan distintas fuentes de alimentación, red y refrigeración, los Acuerdos de Nivel de Servicio (acuerdos de nivel de servicio) pueden incrementar. Para más información, consulte Acuerdos de Nivel de Servicio (SLA) para servicios en línea.

Creación de un recurso con la zona de disponibilidad habilitada

Para obtener información sobre cómo equilibrar la carga de máquinas virtuales dentro de una zona o varias zonas mediante Load Balancer, consulte Inicio rápido: Creación de un equilibrador de carga público para equilibrar la carga de las máquinas virtuales.

Nota:

  • Las zonas no se pueden cambiar, actualizar ni crear para el recurso después de su creación.
  • Los recursos no se pueden actualizar de zonal a con redundancia de zona y viceversa después de su creación.

Tolerancia a errores

Las máquinas virtuales pueden conmutar por error a otro servidor de un clúster, reiniciando el sistema operativo de la máquina virtual en el nuevo servidor. Debe hacer referencia al proceso de conmutación por error para la recuperación ante desastres, recopilar máquinas virtuales en el planeamiento de la recuperación y ejecutar simulacros de recuperación ante desastres para asegurarse de que su solución de tolerancia a errores sea correcta.

Para obtener más información, consulte los procesos de Site Recovery.

Experiencia a nivel de zona

La redundancia de zona no implica un plano de control o un plano de datos sin incidencias. Los flujos con redundancia de zona pueden usar cualquier zona y los flujos que use utilizarán todas las zonas correctas de una región. En el caso de un error de zona, los flujos de tráfico que usan zonas correctas no se ven afectados.

Los flujos de tráfico que están usando una zona en el momento en que se produce un error en esta pueden resultar afectados, pero las aplicaciones se pueden recuperar. El tráfico continúa por las zonas correctas de la región después de la retransmisión cuando Azure ha detectado el error en la zona.

Revise los patrones de diseño en la nube de Azure para mejorar la resistencia de la aplicación a los escenarios de error.

Varios servidores front-end

El uso de varios front-ends le permite equilibrar la carga del tráfico en más de un puerto o dirección IP. Al diseñar la arquitectura, asegúrese de tener en cuenta cómo interactúa la redundancia de zona con varios servidores front-end. Si el objetivo es hacer que cada front-end sea resistente a errores, todas las direcciones IP asignadas como servidores front-end deben tener redundancia de zona. Si un conjunto de front-ends está pensado para asociarse a una sola zona, todas las direcciones IP de ese conjunto se deben asociar a esa zona específica. No se requiere un equilibrador de carga en cada zona. En su lugar, cada front-end zonal (o conjunto de servidores front-end zonales) se podría asociar con máquinas virtuales del grupo de back-end que forman parte de esa zona de disponibilidad específica.

Técnicas de implementación segura

Revise los patrones de diseño en la nube de Azure para mejorar la resistencia de la aplicación a los escenarios de error.

Soporte técnico para la migración a la zona de disponibilidad

En el caso de que una región se aumente para tener zonas de disponibilidad, las IP existentes, como las usadas para los servidores front-end del equilibrador de carga, seguirán siendo no zonales. Para asegurarse de que la arquitectura puede aprovechar las nuevas zonas, se recomienda que cree una nueva dirección IP de front-end. Una vez creado, puede reemplazar el front-end no zonal existente por un nuevo front-end con redundancia de zona. Para obtener información sobre cómo migrar a la compatibilidad con zonas de disponibilidad, consulte asistencia para migrar Load Balancer a zonas de disponibilidad.

Recuperación ante desastres entre regiones y continuidad empresarial

La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.

En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.

Azure Standard Load Balancer admite el equilibrio de carga entre regiones que habilita escenarios de alta disponibilidad con redundancia geográfica como, por ejemplo:

La configuración de direcciones IP de front-end del equilibrador de carga entre regiones es estática y se anuncia a través de la mayoría de las regiones de Azure.

Diagrama del equilibrador de carga entre regiones.

Nota:

El puerto de back-end de la regla de equilibrio de carga del equilibrador de carga entre regiones debe coincidir con el puerto de front-end de la regla de equilibrio de carga o la regla NAT de entrada de la instancia de Standard Load Balancer regional.

Recuperación ante desastres en la geografía de varias regiones

Redundancia regional

Configure la redundancia regional vinculando sin problemas un equilibrador de carga entre regiones a los equilibradores de carga regionales existentes.

Si se produce un error en una región, el tráfico se enruta al siguiente equilibrador de carga regional correcto más cercano.

El sondeo de estado del equilibrador de carga entre regiones recopila información sobre la disponibilidad de cada equilibrador de carga regional cada 5 segundos. Si la disponibilidad de un equilibrador de carga regional baja a 0, el equilibrador de carga entre regiones detecta el error. A continuación, el equilibrador de carga regional se excluye de la rotación.

Diagrama de la vista del tráfico de la región global.

Latencia ultrabaja

El algoritmo de equilibrio de carga de proximidad geográfica se basa en la ubicación geográfica de los usuarios y las implementaciones regionales.

El tráfico iniciado desde un cliente alcanza la región participante más cercana y circulará por la red troncal global de Microsoft para llegar a la implementación regional más cercana.

Por ejemplo, tiene un equilibrador de carga entre regiones con instancias de Standard Load Balancer en las regiones de Azure:

  • Oeste de EE. UU.
  • Norte de Europa

Si se inicia un flujo desde Seattle, el tráfico entra en Oeste de EE. UU. Esta región es la región participante más cercana de Seattle. El tráfico se enruta al equilibrador de carga de la región más cercana, que es Oeste de EE. UU.

El equilibrador de carga entre regiones de Azure usa el algoritmo de equilibrio de carga de proximidad geográfica para la decisión de enrutamiento.

El modo de distribución de carga configurado de los equilibradores de carga regionales se usa para tomar la decisión de enrutamiento final al usarse varios equilibradores de carga regionales para la proximidad geográfica.

Para más información, consulte Configurar el modo de distribución para Azure Load Balancer.

El tráfico de salida sigue las preferencias de enrutamiento establecidas en los equilibradores de carga regionales.

Capacidad de escalar verticalmente o reducir verticalmente detrás de un solo punto de conexión

Cuando expone el punto de conexión global de un equilibrador de carga entre regiones a los clientes, puede agregar o quitar implementaciones regionales detrás del punto de conexión global sin que se produzca ninguna interrupción.

Dirección IP global de difusión por proximidad estática

El equilibrador de carga entre regiones viene con una dirección pública estática, que garantiza que la dirección IP siga siendo la misma. Para obtener más información sobre la dirección IP estática, lea más aquí.

Conservación de la dirección IP de cliente

El equilibrador de carga entre regiones es un equilibrador de carga de red de tránsito de nivel 4. Este tránsito conserva la dirección IP original del paquete. La dirección IP original está disponible para el código que se ejecuta en la máquina virtual. Esta conservación permite aplicar lógica específica de una dirección IP.

Dirección IP flotante

La dirección IP flotante se puede configurar en el nivel de IP global y en el nivel de IP regional. Para más información, consulte Varios front-ends para Azure Load Balancer.

Es importante tener en cuenta que la dirección IP flotante configurada en Load Balancer entre regiones de Azure funciona independientemente de las configuraciones de IP flotantes en equilibradores de carga regionales de back-end. Si la dirección IP flotante está habilitada en el equilibrador de carga entre regiones, es necesario agregar la interfaz de bucle invertido adecuada a las máquinas virtuales de back-end.

Sondeos de estado

El equilibrador de carga entre regiones de Azure utiliza el estado de los equilibradores de carga regionales de back-end a la hora de decidir a dónde distribuir el tráfico. El equilibrador de carga entre regiones hace comprobaciones de estado automáticamente cada 5 segundos, siempre que el usuario haya configurado sondeos de estado en su equilibrador de carga regional.

Compilación de la solución entre regiones en la instancia de Azure Load Balancer existente

El grupo de back-end del equilibrador de carga entre regiones contiene uno o varios equilibradores de carga regionales.

Agregue las implementaciones del equilibrador de carga existentes a un equilibrador de carga entre regiones para una implementación entre regiones altamente disponible.

La región principal es donde se implementa el equilibrador de carga entre regiones o la dirección IP pública del nivel global. Esta región no afecta al modo en que se enruta el tráfico. Si una región principal deja de funcionar, el flujo de tráfico no se ve afectado.

Regiones principales

  • Centro de EE. UU.
  • Este de Asia
  • Este de EE. UU. 2
  • Norte de Europa
  • Sudeste de Asia
  • Sur de Reino Unido 2
  • US Gov - Virginia
  • Oeste de Europa
  • Oeste de EE. UU.

Nota

Solo puede implementar el equilibrador de carga entre regiones o la dirección IP pública de nivel global en una de las regiones de Inicio listadas.

Una región participante es aquella en la que la dirección IP pública global del equilibrador de carga se anuncia.

El tráfico iniciado por el usuario se dirige a la región participante más cercana a través de la red principal de Microsoft.

El equilibrador de carga entre regiones enruta el tráfico al equilibrador de carga regional adecuado.

Diagrama del tráfico global de varias regiones.

Regiones participantes

  • Este de Australia
  • Sudeste de Australia
  • Centro de la India
  • Centro de EE. UU.
  • Este de Asia
  • Este de EE. UU.
  • Este de EE. UU. 2
  • Japón Oriental
  • Centro-Norte de EE. UU
  • Norte de Europa
  • Centro-sur de EE. UU.
  • Sudeste de Asia
  • Sur de Reino Unido
  • US DoD (centro)
  • US DoD (este)
  • US Gov: Arizona
  • US Gov Texas
  • US Gov - Virginia
  • Centro-Oeste de EE. UU.
  • Oeste de Europa
  • Oeste de EE. UU.
  • Oeste de EE. UU. 2

Nota

Los equilibradores de carga regionales de back-end se pueden implementar en cualquier región de Azure disponible públicamente y no se limita solo a las regiones participantes.

Limitaciones

  • Las configuraciones de direcciones IP de front-end entre regiones son solo públicas. Actualmente no se admite un front-end interno.

  • No se puede agregar un equilibrador de carga interno o privado al grupo de back-end del equilibrador de carga entre regiones.

  • La traducción NAT64 no se admite en este momento. Las direcciones IP de front-end y back-end deben ser del mismo tipo (v4 o v6).

  • No se admite el tráfico UDP en Load Balancer entre regiones para IPv6.

  • No se admite el tráfico UDP en el puerto 3 en el equilibrador de carga entre regiones.

  • Las reglas de salida no son compatibles con Load Balancer entre regiones. Para las conexiones salientes, use reglas de salida en el equilibrador de carga regional o en la puerta de enlace NAT.

Precios y contrato de nivel de servicio

El equilibrador de carga entre regiones comparte el Acuerdo de Nivel de Servicio de la instancia del equilibrador de carga estándar.

Pasos siguientes