**Ayude a mejorar esta página**
Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página.
# Cómo preparar las redes para los nodos híbridos
En este tema se ofrece información general sobre la configuración de red que se debe establecer antes de crear el clúster de Amazon EKS y conectar los nodos híbridos. En esta guía se presupone que ha cumplido los requisitos previos para la conectividad de red híbrida mediante [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html), [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) o una solución de VPN propia.
![\[Conectividad de red de nodos híbridos.\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-prereq-diagram.png)
## Configuración de redes en las instalaciones
### Requisitos mínimos de red
Para disfrutar de una experiencia óptima, recomendamos una conectividad de red fiable de al menos 100 Mbps y un máximo de 200 ms de latencia de ida y vuelta para la conexión de los nodos híbridos a la región de AWS. Esta es una guía general que se adapta a la mayoría de los casos de uso, pero no es un requisito estricto. Los requisitos de ancho de banda y latencia pueden variar en función de la cantidad de nodos híbridos y de las características de la carga de trabajo, como el tamaño de la imagen de la aplicación, la elasticidad de la aplicación, las configuraciones de supervisión y registro, y las dependencias de la aplicación para acceder a datos almacenados en otros servicios de AWS. Recomendamos que realice pruebas con aplicaciones y entornos propios antes de la implementación en la fase de producción con el fin de comprobar que la configuración de red cumple los requisitos de las cargas de trabajo.
### CIDR de nodos y pods en las instalaciones
Identifique los CIDR de nodos y pods que utilizará para los nodos híbridos y las cargas de trabajo que se ejecutan en estos. El CIDR de nodos se asigna desde la red en las instalaciones y el CIDR de pods se asigna desde la interfaz de red del contenedor (CNI) si se utiliza una red superpuesta para la CNI. Transmite los CIDR de los nodos en las instalaciones y los CIDR de los pods como entradas al crear su clúster de EKS con los campos `RemoteNodeNetwork` y `RemotePodNetwork`. Los CIDR de los nodos en las instalaciones deben ser enrutables en su red local. Consulte la siguiente sección para obtener información sobre la enrutabilidad del CIDR del pod en las instalaciones.
Los bloques de CIDR del pod y del nodo en las instalaciones deben cumplir los siguientes requisitos:
1. Estar dentro de uno de los siguientes rangos `IPv4` RFC-1918: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16`, o dentro del rango CGNAT definido por RFC 6598: `100.64.0.0/10`.
1. Que no se solapen entre sí, el CIDR de la VPC del clúster de EKS o el CIDR `IPv4` del servicio de Kubernetes.
### Enrutamiento de red del pod en las instalaciones
Si utiliza los nodos híbridos de EKS, generalmente recomendamos que configure los CIDR del pod en las instalaciones de manera tal que se puedan enrutar en su red local para permitir la comunicación y la funcionalidad completas del clúster entre los entornos de la nube y los que están en las instalaciones.
**Redes de pods enrutables**
Si puede configurar la red de los pods para que se pueda enrutar en su red en las instalaciones, siga las instrucciones que se indican a continuación.
1. Configure el campo `RemotePodNetwork` para su clúster de EKS con el CIDR del pod en las instalaciones, sus tablas de enrutamiento de VPC con el CIDR del pod en las instalaciones y el grupo de seguridad de su clúster de EKS con el CIDR del pod en las instalaciones.
1. Existen varias técnicas que puede utilizar para hacer que el CIDR de los pods en las instalaciones sea enrutable en la red en las instalaciones, como el protocolo de puerta de enlace fronteriza (BGP), rutas estáticas u otras soluciones de enrutamiento personalizadas. BGP es la solución recomendada, ya que es más escalable y fácil de administrar que las soluciones alternativas que requieren configuración manual o personalizada de rutas. AWS admite las capacidades de BGP de Cilium y Calico para anunciar los CIDR de los pods. Consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md) y [CIDR de pod remoto enrutable](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) para obtener más información.
1. Los webhooks se pueden ejecutar en nodos híbridos, ya que el plano de control de EKS puede comunicarse con las direcciones IP del pod asignadas a los webhooks.
1. Las cargas de trabajo que se ejecutan en los nodos de la nube pueden comunicarse directamente con las cargas de trabajo que se ejecutan en los nodos híbridos del mismo clúster de EKS.
1. Otros servicios de AWS, como los equilibradores de carga de aplicación de AWS y Amazon Managed Service para Prometheus, pueden comunicarse con las cargas de trabajo que se ejecutan en nodos híbridos para equilibrar el tráfico de red y analizar las métricas de los pods.
**Redes de pods no enrutables**
Si *no* puede hacer que las redes de los pods se enruten en la red en las instalaciones, siga las instrucciones que se indican a continuación.
1. Los webhooks no se pueden ejecutar en nodos híbridos, ya que requieren conectividad desde el plano de control de EKS a las direcciones IP de los pods asignadas a los webhooks. En este caso, le recomendamos que ejecute los webhooks en los nodos de la nube del mismo clúster de EKS que los nodos híbridos; consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md) para obtener más información.
1. Las cargas de trabajo que se ejecutan en los nodos de la nube no pueden comunicarse directamente con las cargas de trabajo que se ejecutan en los nodos híbridos cuando se utiliza la CNI de la VPC para los nodos de la nube y Cilium o Calico para los nodos híbridos.
1. Utilice la distribución de tráfico del servicio para mantener el tráfico local en la zona de origen. Para obtener más información sobre la distribución de tráfico del servicio, consulte [Configurar la distribución de tráfico del servicio](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-service-traffic-distribution).
1. Configure su CNI para que utilice la máscara de salida o la traducción de direcciones de red (NAT) para el tráfico de los pods cuando salga de los hosts en las instalaciones. Esta opción está habilitada de forma predeterminada en Cilium. Calico requiere que `natOutgoing` se establezca en `true`.
1. Otros servicios de AWS, como los equilibradores de carga de aplicación de AWS y Amazon Managed Service para Prometheus, no pueden comunicarse con las cargas de trabajo que se ejecutan en nodos híbridos.
### Se requiere acceso durante la instalación y actualización de nodos híbridos
Debe tener acceso a los siguientes dominios durante el proceso de instalación en el que instala las dependencias de los nodos híbridos en los hosts. Este proceso se puede realizar una vez al crear las imágenes del sistema operativo o en cada host en tiempo de ejecución. Esto incluye la instalación inicial y cuando se actualiza la versión de Kubernetes de los nodos híbridos.
Algunos paquetes se instalan mediante el administrador de paquetes predeterminado del sistema operativo. En AL2023 y RHEL, el comando `yum` se usa para instalar `containerd`, `ca-certificates`, `iptables` y `amazon-ssm-agent`. En Ubuntu, `apt` se usa para instalar `containerd`, `ca-certificates` y `iptables`, mientras que `snap` se usa para instalar `amazon-ssm-agent`.
| Componente | URL | Protocolo | Puerto |
| --- | --- | --- | --- |
| Artefactos de nodos de EKS (S3) | https://hybrid-assets.eks.amazonaws.com | HTTPS | 443 |
| [Puntos de conexión de servicio de EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | https://eks.*region*.amazonaws.com | HTTPS | 443 |
| [Puntos de conexión de servicio de ECR](https://docs.aws.amazon.com/general/latest/gr/ecr.html) | https://api.ecr.*region*.amazonaws.com | HTTPS | 443 |
| Puntos de conexión de ECR de EKS | Consulte [Visualización de los registros de imágenes de contenedores de Amazon para los complementos de Amazon EKS](add-ons-images.md) para conocer los puntos de conexión regionales. | HTTPS | 443 |
| Punto de conexión binario SSM 1 | https://amazon-ssm-*region*.s3.*region*.amazonaws.com | HTTPS | 443 |
| [Punto de conexión de servicio de SSM](https://docs.aws.amazon.com/general/latest/gr/ssm.html) 1 | https://ssm.*region*.amazonaws.com | HTTPS | 443 |
| Punto de conexión binario de IAM Anywhere 2 | https://rolesanywhere.amazonaws.com | HTTPS | 443 |
| [Punto de conexión de servicio de IAM Anywhere](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) 2 | https://rolesanywhere.*region*.amazonaws.com | HTTPS | 443 |
| Puntos de conexión del administrador de paquetes del sistema operativo | Los puntos de conexión del repositorio de paquetes son específicos del sistema operativo y pueden variar según la región geográfica. | HTTPS | 443 |
**nota**
1 El acceso a los puntos de conexión de AWS SSM solo es necesario si utiliza activaciones híbridas de AWS SSM para el proveedor de credenciales de IAM en las instalaciones.
2 El acceso a los puntos de conexión de AWS IAM solo es necesario si utiliza AWS IAM Roles Anywhere como proveedor de credenciales de IAM en las instalaciones.
### Acceso necesario para las operaciones de clúster en curso
El siguiente acceso a la red para el firewall en las instalaciones es necesario para las operaciones de clúster en curso.
**importante**
Según el CNI que elija, deberá configurar reglas de acceso a la red adicionales para los puertos del CNI. Consulte la documentación de [Cilium](https://docs.cilium.io/en/stable/operations/system_requirements/#firewall-rules) y la documentación de [Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/requirements#network-requirements) para obtener más información.
| Tipo | Protocolo | Dirección | Puerto | Origen | Destino | Uso |
| --- | --- | --- | --- | --- | --- | --- |
| HTTPS | TCP | Salida | 443 | CIDR de nodos remotos | IP de clúster de EKS 1 | Servidor de API de kubelet a Kubernetes |
| HTTPS | TCP | Salida | 443 | CIDR de pods remotos | IP de clúster de EKS 1 | Pod a servidor de API de Kubernetes |
| HTTPS | TCP | Salida | 443 | CIDR de nodos remotos | [Punto de conexión de servicio de SSM](https://docs.aws.amazon.com/general/latest/gr/ssm.html) | Actualización de credenciales de activaciones híbridas de SSM y señales de SSM cada 5 minutos |
| HTTPS | TCP | Salida | 443 | CIDR de nodos remotos | [Punto de conexión del servicio IAM Anywhere](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) | Actualización de credenciales de IAM Roles Anywhere |
| HTTPS | TCP | Salida | 443 | CIDR de pods remotos | [Punto de conexión regional de STS](https://docs.aws.amazon.com/general/latest/gr/sts.html) | Pod a punto de conexión de STS. Obligatorio solo para IRSA |
| HTTPS | TCP | Salida | 443 | CIDR de nodos remotos | [Punto de conexión del servicio Auth de Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) | Nodo a punto de conexión de autenticación de Amazon EKS. Obligatorio solo para Pod Identity de Amazon EKS |
| HTTPS | TCP | Entrada | 10250 | IP de clúster de EKS 1 | CIDR de nodos remotos | Servidor de la API de Kubernetes a kubelet |
| HTTPS | TCP | Entrada | Puertos de webhook | IP de clúster de EKS 1 | CIDR de pods remotos | Servidor de la API de Kubernetes a webhooks |
| HTTPS | TCP,UDP | Entrada,Salida | 53 | CIDR de pods remotos | CIDR de pods remotos | Pod a CoreDNS. Si ejecuta al menos una réplica de CoreDNS en la nube, debe permitir el tráfico DNS a la VPC donde se ejecuta CoreDNS. |
| Definido por el usuario | Definido por el usuario | Entrada,Salida | Puertos de la aplicación | CIDR de pods remotos | CIDR de pods remotos | Pod a pod |
**nota**
1 Las direcciones IP del clúster de EKS. Consulte la siguiente sección sobre las interfaces de red elásticas de Amazon EKS.
### Interfaces de red de Amazon EKS
Amazon EKS asocia interfaces de red a las subredes de la VPC que se transmiten durante la creación del clúster para permitir la comunicación entre el plano de control de EKS y la VPC. Las interfaces de red que Amazon EKS crea se pueden encontrar tras la creación del clúster en la consola de Amazon EC2 o con la AWS CLI. Las interfaces de red originales se eliminan y se crean nuevas interfaces de red cuando se aplican cambios en el clúster de EKS, como actualizaciones de la versión de Kubernetes. Para restringir el rango de IP de las interfaces de red de Amazon EKS, es posible utilizar tamaños de subred limitados para las subredes que se transmiten durante la creación del clúster, lo que facilita la configuración del firewall en las instalaciones para permitir la conectividad entrante/saliente a este conjunto de IP conocidas y limitadas. Para controlar en qué subredes se crean las interfaces de red, puede limitar la cantidad de subredes que especifica al crear un clúster o puede actualizar las subredes después de crear el clúster.
Las interfaces de red aprovisionadas por Amazon EKS tienen una descripción del formato `Amazon EKS your-cluster-name `. Consulte el ejemplo que aparece a continuación para ver un comando de la AWS CLI que se puede utilizar para buscar las direcciones IP de las interfaces de red que Amazon EKS aprovisiona. Sustituya `VPC_ID` por el ID de la VPC que se transmite durante la creación del clúster.
```
aws ec2 describe-network-interfaces \
--query 'NetworkInterfaces[?(VpcId == VPC_ID && contains(Description,Amazon EKS))].PrivateIpAddress'
```
## AWS VPC y configuración de subredes
Los [requisitos de VPC y subredes existentes](network-reqs.md) para Amazon EKS se aplican a los clústeres con nodos híbridos. Además, el CIDR de la VPC no se puede solapar con los CIDR de los nodos y pods en las instalaciones. Debe configurar rutas en la tabla de enrutamiento de la VPC para el CIDR de nodos en las instalaciones y, opcionalmente, el CIDR de pods. Estas rutas se deben configurar para dirigir el tráfico a la puerta de enlace que se utiliza para la conectividad de la red híbrida, que comúnmente es una puerta de enlace privada virtual (VGW) o una puerta de enlace de tránsito (TGW). Si está utiliza TGW o VGW para conectar la VPC con el entorno en las instalaciones, debe crear una conexión TGW o VGW para la VPC. La VPC debe tener un nombre de host DNS y admitir la resolución DNS.
Para los siguientes pasos, se utiliza la AWS CLI. También puede crear estos recursos en la Consola de administración de AWS o con otras interfaces, como AWS CloudFormation, AWS CDK o Terraform.
### Paso 1: Creación de la VPC
1. Ejecute el siguiente comando para crear una VPC. Sustituya VPC\$1CIDR por uno de los siguientes rangos IPv4 CIDR: RFC 1918 (privado), CGNAT (RFC 6598) o no RFC 1918/no CGNAT (público) (por ejemplo, 10.0.0.0/16). Nota: La resolución de DNS, que es un requisito de EKS, está habilitada para la VPC de forma predeterminada.
```
aws ec2 create-vpc --cidr-block VPC_CIDR
```
1. Habilite los nombres de host de DNS para la VPC. Nota: La resolución de DNS está habilitada para la VPC de forma predeterminada. Sustituya `VPC_ID` por el ID de la VPC que creó en el paso anterior.
```
aws ec2 modify-vpc-attribute --vpc-id VPC_ID --enable-dns-hostnames
```
### Paso 2: Creación de subredes
Cree al menos 2 subredes. Amazon EKS usa estas subredes para las interfaces de red del clúster. Para obtener más información, consulte [Requisitos y consideraciones de las subredes](network-reqs.md#network-requirements-subnets).
1. Puede buscar las zonas de disponibilidad de una región de AWS con el siguiente comando. Reemplace `us-west-2` por la región.
```
aws ec2 describe-availability-zones \
--query 'AvailabilityZones[?(RegionName == us-west-2)].ZoneName'
```
1. Cree una subred. Sustituya `VPC_ID` por el ID de la VPC. Sustituya `SUBNET_CIDR` por el bloque de CIDR de la subred (por ejemplo, 10.0.1.0/24). Sustituya `AZ` por la zona de disponibilidad en la que se creará la subred (por ejemplo, us-west-2a). Las subredes que cree deben estar en al menos dos zonas de disponibilidad diferentes.
```
aws ec2 create-subnet \
--vpc-id VPC_ID \
--cidr-block SUBNET_CIDR \
--availability-zone AZ
```
### (Opcional) Paso 3: adjunción de una VPC con la puerta de enlace de tránsito (TGW) de Amazon VPC o una puerta de enlace privada virtual (VGW) de AWS Direct Connect
Si utiliza una TGW o VGW, conecte la VPC a la TGW o VGW. Para obtener más información, consulte [Amazon VPC attachments in Amazon VPC Transit Gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html) o [AWS Direct Connect virtual private gateway associations](https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html#VPNGateway).
**Transit Gateway**
Ejecute el siguiente comando para conectar una puerta de enlace de tránsito. Sustituya `VPC_ID` por el ID de la VPC. Sustituya `SUBNET_ID1` y `SUBNET_ID2` por el ID de las subredes que creó en el paso anterior. Sustituya `TGW_ID` por el ID de la TGW.
```
aws ec2 create-transit-gateway-vpc-attachment \
--vpc-id VPC_ID \
--subnet-ids SUBNET_ID1 SUBNET_ID2 \
--transit-gateway-id TGW_ID
```
**Puerta de enlace privada virtual**
Ejecute el siguiente comando para conectar una puerta de enlace de tránsito. Sustituya `VPN_ID` por el ID de la VGW. Sustituya `VPC_ID` por el ID de la VPC.
```
aws ec2 attach-vpn-gateway \
--vpn-gateway-id VPN_ID \
--vpc-id VPC_ID
```
### (Opcional) Paso 4: Creación de una tabla de enrutamiento
Puede modificar la tabla de enrutamiento principal de la VPC o puede crear una tabla de enrutamiento personalizada. En los siguientes pasos, se crea una tabla de enrutamiento personalizada con las rutas a los CIDR de nodos y pods en las instalaciones. Para obtener más información, consulte [Tablas de enrutamiento de subredes](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-route-tables.html). Sustituya `VPC_ID` por el ID de la VPC.
```
aws ec2 create-route-table --vpc-id VPC_ID
```
### Paso 5: Creación de rutas para nodos y pods en las instalaciones
Cree rutas en la tabla de enrutamiento para cada uno de los nodos remotos en las instalaciones. Puede modificar la tabla de enrutamiento principal de la VPC o utilizar la tabla de enrutamiento personalizada que creó en el paso anterior.
En los ejemplos que aparecen a continuación se muestra cómo crear rutas para los CIDR de nodos y pods en las instalaciones. En los ejemplos, se utiliza una puerta de enlace de tránsito (TGW) para conectar la VPC con el entorno en las instalaciones. Si tiene múltiples CIDR de nodos y pods en las instalaciones, repita los pasos para cada CIDR.
+ Si utiliza una puerta de enlace de Internet o una puerta de enlace privada virtual (VGW), sustituya `--transit-gateway-id` por `--gateway-id`.
+ Sustituya `RT_ID` por el ID de la tabla de enrutamiento que creó en el paso anterior.
+ Sustituya `REMOTE_NODE_CIDR` por el rango de CIDR que utilizará para los nodos híbridos.
+ Sustituya `REMOTE_POD_CIDR` por el rango de CIDR que utilizará para los pods que se ejecutan en nodos híbridos. El rango de CIDR del pod corresponde a la configuración de la interfaz de red de contenedores (CNI), que habitualmente utiliza una red superpuesta en las instalaciones. Para obtener más información, consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).
+ Sustituya `TGW_ID` por el ID de la TGW.
**Red de nodos remotos**
```
aws ec2 create-route \
--route-table-id RT_ID \
--destination-cidr-block REMOTE_NODE_CIDR \
--transit-gateway-id TGW_ID
```
**Red de pods remotos**
```
aws ec2 create-route \
--route-table-id RT_ID \
--destination-cidr-block REMOTE_POD_CIDR \
--transit-gateway-id TGW_ID
```
### (Opcional) Paso 6: Asociación de las subredes a la tabla de enrutamiento
Si creó una tabla de enrutamiento personalizada en el paso anterior, asocie cada una de las subredes que creó en el paso anterior a la tabla de enrutamiento personalizada. Si va a modificar la tabla de enrutamiento principal de la VPC, las subredes se asociarán automáticamente a la tabla de enrutamiento principal de la VPC y podrá omitir este paso.
Ejecute el siguiente comando para cada una de las subredes que creó en los pasos anteriores. Sustituya `RT_ID` por la tabla de enrutamiento que creó en el paso anterior. Sustituya `SUBNET_ID` por el ID de una subred.
```
aws ec2 associate-route-table --route-table-id RT_ID --subnet-id SUBNET_ID
```
## Configuración del grupo de seguridad del clúster
El siguiente acceso para el grupo de seguridad del clúster de EKS se necesita para las operaciones de clúster en curso. Amazon EKS crea automáticamente las reglas de grupo de seguridad de **entrada** necesarias para los nodos híbridos al crear o actualizar el clúster con las redes de nodos y pods remotos configuradas. Como los grupos de seguridad permiten todo el tráfico **saliente** de forma predeterminada, Amazon EKS no modifica automáticamente las reglas de **salida** del grupo de seguridad del clúster para los nodos híbridos. Si desea personalizar el grupo de seguridad del clúster, puede limitar el tráfico a las reglas de la siguiente tabla.
| Tipo | Protocolo | Dirección | Puerto | Origen | Destino | Uso |
| --- | --- | --- | --- | --- | --- | --- |
| HTTPS | TCP | Entrada | 443 | CIDR de nodos remotos | N/A | Servidor de la API de Kubelet a Kubernetes |
| HTTPS | TCP | Entrada | 443 | CIDR de pods remotos | N/A | Pods que requieren acceso al servidor de la API de K8s cuando el CNI no utiliza NAT para el tráfico de pods. |
| HTTPS | TCP | Salida | 10250 | N/A | CIDR de nodos remotos | Servidor de la API de Kubernetes a Kubelet |
| HTTPS | TCP | Salida | Puertos de webhook | N/A | CIDR de pods remotos | Servidor de la API de Kubernetes a webhook (si se ejecutan webhooks en nodos híbridos) |
**importante**
**Límites de reglas de grupos de seguridad**: los grupos de seguridad de Amazon EC2 tienen un máximo de 60 reglas de entrada de forma predeterminada. Es posible que las reglas de entrada de los grupos de seguridad no se apliquen si el grupo de seguridad del clúster se acerca a este límite. En este caso, puede que sea necesario agregar manualmente las reglas de entrada que faltan.
**Responsabilidad de limpiar el CIDR**: si se eliminan las redes de nodos o pods remotos de los clústeres de EKS, EKS no elimina automáticamente las reglas de los grupos de seguridad correspondientes. Usted tiene la responsabilidad de eliminar manualmente las redes de nodos o pods remotos que no se utilicen de las reglas de su grupo de seguridad.
Para obtener más información acerca del grupo de seguridad de clúster que crea Amazon EKS, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md).
### (Opcional) Configuración manual del grupo de seguridad
Si necesita crear grupos de seguridad adicionales o modificar las reglas que se crean automáticamente, puede utilizar los siguientes comandos como referencia. De forma predeterminada, el siguiente comando crea un grupo de seguridad que permite todos los accesos salientes. Puede restringir el acceso saliente para incluir únicamente las reglas indicadas anteriormente. Si considera limitar las reglas de salida, recomendamos que pruebe exhaustivamente la conectividad de todas las aplicaciones y pods antes de aplicar las reglas modificadas a un clúster en fase de producción.
+ En el primer comando, sustituya `SG_NAME` por el nombre del grupo de seguridad
+ En el primer comando, sustituya `VPC_ID` por el ID de la VPC que creó en el paso anterior
+ En el segundo comando, sustituya `SG_ID` por el ID del grupo de seguridad que creó en el primer comando
+ En el segundo comando, sustituya `REMOTE_NODE_CIDR` y `REMOTE_POD_CIDR` por los valores de los nodos híbridos y la red en las instalaciones.
```
aws ec2 create-security-group \
--group-name SG_NAME \
--description "security group for hybrid nodes" \
--vpc-id VPC_ID
```
```
aws ec2 authorize-security-group-ingress \
--group-id SG_ID \
--ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "REMOTE_NODE_CIDR"}, {"CidrIp": "REMOTE_POD_CIDR"}]}]'
```