Introducción.
AWS anunció en julio de 2023 que todas las direcciones IPv4 públicas a partir del 1 de febrero de 2024 tendrían coste.
Hasta ahora, en AWS solo se pagaba por direcciones IPv4 públicas cuando no estaban asignadas a ningún recurso, y algunas personas piensan que es terrible que AWS esté tratando de ganar más dinero ...
Pero otras personas como nosotros pensamos que eso no es gran cosa y que es una excelente oportunidad para guardar direcciones IPv4.
(AWS sigue perdiendo dinero por cada dirección IPv4 aún facturándolas)
Tenemos un gran problema con las direcciones IPv4; Cuando DARPA (Defense Advanced Research Projects Agency) escribió el protocolo en 1981, nadie pensó que se agotarían 4.294.967.296 IP en el futuro.
En aquella época, los ordenadores personales eran raros, la Web no existía y nadie podía imaginar la idea de los smartphones, o de los dispositivos IOT.
En 2011, IANA (Internet Assigned Numbers Authority) asignó los últimos bloques de direcciones IPv4. Si ahora necesitamos una dirección IPv4 hay que comprarla a cualquier persona que tenga una dirección IPv4 sin usar, lo que crea muchos problemas para cualquier empresa que necesite una dirección IPv4.
A finales de 1995, el IETF (Internet Engineering Task Force) comenzó a escribir un nuevo protocolo (IPv6) porque sabían en ese momento que las direcciones IPv4 se agotarían en unos pocos años. En ese momento Internet estaba en una etapa temprana de adopción (pocas personas lo usaban).
La adopción de IPv6 es demasiado lenta. Muchas empresas de telecomunicaciones utilizan IPv6, y nosotros, como usuarios de ellas, utilizamos IPv6. Aun así, muchas empresas que publican servicios en Internet no lo utilizan porque es un cambio difícil de implementar rápidamente.
Esa es la razón de este cambio. Es necesario utilizar menos direcciones IPv4; Si AWS no traspasa ese coste, se seguirán usando muchas direcciones IPv4.
Y desspues de esta introduccion la grandes preguntas que aparecen son:
- ¿Cuántas direcciones IPv4 se estan usando en AWS?
- ¿Cuánto cobrará AWS por estas IPs?
- ¿Y cómo se puede reducir el número de IPv4 fácilmente sin usar IPv6?
Cómo conocer las direcciones IPv4 que estan en uso.
Con este anuncio, AWS lanzó una herramienta para descubrir, analizar y auditar las direcciones IPv4 públicas que se utilizan. Esta herramienta se llama Amazon VPC IP Address Management (IPAM).
Antes de profundizar en este tema, debemos diferenciar cuatro tipos de direcciones IPv4 públicas en AWS:
- EC2 public IP addresses: Las direcciones IPv4 públicas se toman de un grupo de Amazon y solo se asocian con las instancias EC2. Al detener, hibernar o finalizar la instancia, la IP se devuelve al grupo y no se puede reutilizar.
- Elastic IP addresses: Direcciones IPv4 públicas que se pueden asignar a las cuentas. Se pueden asociar y desasociar de instancias según sea necesario. Se asignan hasta que se decide liberarlas (de la cuenta y no del servicio)
- Service-managed public IPv4 addresses IPs de servicios administrados desde Internet de AWS implementados en su cuenta.: Elastic Load Balancers, NAT Gateways, AWS Global Accelerator, AWS Site-to-Site VPN...
- BYOIP addresses (IP públicas que te pertenecen y que puedes traer hacia AWS) AWS no te cobrará por traer tu propio espacio de IPs públicas Estás IP se pueden usar en grupos para asignarlas a las instancias EC2 o puertas de enlace NAT.
Teniendo esto eso en cuenta, ahora es el momento de utilizar el IPAM de Amazon VPC para comprobar el espacio público IPv4 que está en uso y tus recursos.
- Inicie sesión en tu cuenta de AWS.
- Busque Amazon VPC IP Address Manager en la barra de búsqueda.
- Haga clic en “Create IPAM.”
- Seleccione las opciones marcadas:
Notas:
- En el nivel gratuito se realizarán las comprobaciones de tu cuenta para las direcciones IPv4 públicas.
- En el nivel avanzado verificará en toda la organización las direcciones IP públicas y privadas.
- Puedes agregarle un tag de nombre o una descripción (opcional)
- Haga clic en “Add All Regions” para realizar un informe sobre nuestra infraestructura global
- Luego, haga clic en “Create IPAM.”
Después de unos minutos, podrá ver un informe con todas las IPv4 públicas en el menú Public IP Insights:
Por cada IPv4 en uso, AWS facturará $0,005 por hora; esto significa 0,005 x 8760 horas en un año = *$43,8 por año por cada IPv4 *.
Si se tienen 10 IP en uso, se pagarán $438 por estas direcciones IP.
Si se tienen 100... se sumarán $4380.
Si se tienen 1000... bueno... se agregara otro 0.
¿Cómo puedo optimizar mi arquitectura para reducir el uso de IPv4?
Usar un Load Balancer.
Usar un Load Balancer para exponer nuestra aplicación es una de las buenas prácticas de AWS y reduce la cantidad de IP públicas; en lugar de usar una IP para cada EC2, usaremos una IP por subred donde esté implementado el ALB.
Ventajas:
- Mejora tu disponibilidad porque los ALBs trabajan en una configuración de alta disponibilidad.
- Permite la escalabilidad utilizando Auto Scaling Groups como Targets del Load Balancer.
- Permite desacoplar la encriptación SSL utilizando certificados en el propio Load Balancer.
- Tu seguridad puede mejorar utilizando las reglas del WAF.
- Se puede usar puertos HTTP o HTTPS usando ALB o cualquier puerto TCP usando NLB.
Desventajas:
- Costo (no demasiado, pero agrega coste a la solución)
Usar un Load Balancer haciendo de proxy inverso
¿Qué pasa si implementamos muchos Load Balancers con pocas instancias EC2? Eso es un problema porque estamos desperdiciando muchas IP (y balanceadores de carga)
Desde 2017, AWS admite el uso de un Application Load Balancer como un proxy inverso. Esta es una mejora notable porque podemos usar un Load Balancer para múltiples grupos objetivo dependiendo de la cabecera host con la URL solicitada.
Con esta funcionalidad, se puede utilizar un solo Load Balancer para todas las aplicaciones.
¿Pero qué pasa con el cifrado? Necesitamos utilizar varios certificados, uno por URL.
Podrías usar la misma zona DNS y un certificado wildcard. Aun así, no es una muy buena idea y a los equipos de seguridad no les gustan los certificados wildcard (existen algunos problemas de seguridad con los certificados wildcard...)
Pero podemos usar otra característica interesante de ALB como SNI (Server Name Indicator) que permite usar múltiples certificados para diferentes nombres DNS en el mismo ALB.
Ventajas:
- Reducir el número de IP Públicas utilizadas por las aplicaciones
- Reducir el número de ALB utilizados por las aplicaciones.
- Se ahorran costes porque menos ALB e IP públicas significan menos costes.
- Centralizar la gestión de ALBs.
Desventajas:
- Crea una dependencia de otros equipos. Si hay varios stacks para gestionar cada aplicación, se crea una dependencia con el stack que contiene el ALB centralizado.
- Puede ser un problema al usar WAF porque las reglas de WAF son las mismas para todas las aplicaciones y algunas reglas deben ser más específicas.
- La solución sólo funciona en una implementación de múltiples cuentas. Los ALB pueden enviar solicitudes a Target Groups en la misma cuenta, pero no a Target Groups en otras cuentas. Los ALB permiten enviar solicitudes a las IP de otras cuentas (si existe conectividad privada), pero eso no permite elasticidad. Se podría usar un servidor proxy inverso en una EC2, pero no es una solución administrada y genera más sobrecarga operativa.
Usar un Bastion
Usar un Bastion host es una solución típica para acceder a servidores en la nube; en lugar de agregar una dirección IP pública a cualquier servidor que se administra, se crea un Bastion Host con una IP pública y se inicia sesión en este Bastion Host usando SSH o RDP (dependiendo del sistema operativo de nuestro Bastion Hosts). Desde este bastión podremos saltar a las EC2 o RDS.
Esa es una forma segura de acceder los recursos porque se puede limitar el alcance del security group agregando solo las IP públicas que se usan desde la red corporativa o las IP públicas individuales de los Admins.
Desde el Bastion Host se puede acceder a cualquier EC2, RDS, ECS, EKS, etc.
Solo es necesario agregar el security group o IP del Bastion Host a los security group para las instancias a las que necesitamos acceso.
Podemos acceder a la VPC donde está el Bastion Host, pero también podemos acceder a otras VPC si implementamos el peering de VPC o implementamos una topología de Transit Gateway.
Estas interconexiones entre VPC permiten centralizar nuestro Bastion host de forma que se reduce y simplifica la infraestructura de gestión.
Este método es fácil de usar; un Bastion Host es algo habitual; se puede usar diferentes claves de acceso, diferentes usuarios del sistema operativo, es auditable, etc.
Además, si es necesario una forma más segura de acceder, se puede usar un Cliente VPN en lugar de una conexión directa a los Bastion Hosts usando SSH o RDP.
Ventajas:
- Se reduce la cantidad de IP públicas utilizadas para administrar instancias.
- Se mejora la seguridad porque hay menos puntos de entrada a los servidores.
- Se necesita mantener menos instancias para la administración.
- Un Bastion Host es una topología familiar en infraestructura de TI.
- Se pueden guardar los logs de acceso al Bastion host y auditar la actividad.
Desventajas:
- Se necesita una EC2 para la gestión.
- Se debe gestionar y auditar security group para limitar el acceso a nuestro Bastion Host.
- Existe riesgo de exponer la infraestructura si alguien obtiene acceso a Bastion Host.
- Se pueden recibir ataques de fuerza bruta SSH y se debe implementar métodos de protección.
Usar Session Manager
AWS Systems Manager Session Manager (SSM)](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) es una manera de acceder a instancias EC2 como si estuviéramos usando SSH pero sin utilizarlo, con beneficios adicionales de seguridad de AWS.
Para usar SSM, se tienen que cumplir unos requisitos:
- Es necesario tener los agentes SSM instalados en las instancias (Si se usa una AMI de AWS, el agente viene instalado por defecto).
- La Instancia necesita acceso al endpoint de SSM usando un NAT Gateway o desplegando un endpoint privado de AWS.
- Es necesario añadir un perfil de Instancia con permisos a SSM para permitir al EC2 ejecutar algunas llamadas API a servicios SSM.
- Es necesario permisos para usar SSM en el usuario o rol de IAM.
Se pude realizar la configuración usando la Documentación de AWS.
Este método de acceso permite iniciar sesión en una instancia sin utilizar SSH, utilizando las credenciales de IAM. Esto es muy útil porque se puede utilizar IAM identity Center y centralizar el acceso a los sistemas utilizando las credenciales de un IdP en lugar de las credenciales locales de Linux.
Además, si se utiliza IAM Identity Center o IAM Roles, se estan utilizando credenciales de seguridad temporales que mejoran significativamente la seguridad. Esas credenciales rotan muy a menudo (sólo están activas durante unas horas o menos si así se decide). Si alguien roba estas credenciales, se revocarán automáticamente cuando caducara el token, y también se pueden revocar las credenciales inmediatamente.
Si se utilizan servidores Windows, se puede utilizar AWS Systems Manager Fleet Manager, que utiliza un sistema similar pero para conexiones RDP.
También, es posible utilizar una mezcla de SSM con un Bastion Host privado.
Es el mismo método que si se utilizara un Bastion Host pero sin exponerlo a Internet.
Sin embargo, SSM es inutilizable para algunas personas porque necesitan usar X11 en servidores remotos o subir archivos usando SCP o la terminal en lugar de la consola de AWS o AWS CLI.
Pero no hay problema; SSM tiene una característica llamada Port Forwarding que nos permite crear un túnel desde un ordenador a los Bastion Hosts y conectarse a otros servidores directamente. Es como un túnel SSH y es muy potente.
Se puede acceder a los servidores RDS o sitios web privados sin publicarlos. También se puede reenviar X11 y utilizar consolas gráficas remotas.
Ventajas:
- No es necesario usar IPs Públicas
- Se utilizan credenciales IAM con credenciales temporales en lugar de credenciales Linux o claves SSH.
- Es posible usar credenciales IdP para iniciar sesión en instancias EC2.
- Se puede tener una conexión cifrada HTTPs cifrada por AWS.
- No se exponen los servidores en internet.
- Es posible auditar logs y acciones.
- Se pueden explorar logs en Cloudwatch y crear métricas y alarmas.
- Es posible revocar credenciales automáticamente.
- Se puede utilizar la función de reenvío de puertos para crear túneles seguros.
- La solución no tiene ningún coste; SSM es gratuito.
Desventajas:
- Es necesario utilizar AWS CLI o la consola de AWS para conectarse a los servidores.
- El método es más complejo y es necesario que los usuarios estén familiarizados con este tipo de túneles.
- Es necesario instalar agentes y crear perfiles de Instancia.
Usar EC2 Instance connect de manera privada.
El servicio EC2 Instance Connect (EIC) permite conectar con las instancias EC2 públicas/privadas estableciendo una sesión SSH a través del navegador. La API de instance connect publicará una clave pública SSH de un solo uso en los metadatos de la instancia EC2, que permanecerá ahí durante 60 segundos.
Si la instancia tiene instalado EC2 Instance Connect, un daemon SSH extraerá la información de la clave pública de los metadatos de la instancia para la autenticación en este periodo de tiempo.
La conexión SSH se establecerá utilizando la clave privada de un solo uso que la API de Instance Connect generó en el momento de la solicitud.
IAM respalda el servicio; ningún usuario que no tenga acceso a este servicio podrá conectarse. Para obtener más información sobre el funcionamiento del servicio, se puede consultar la guía del usuario.
Inicialmente, EC2 instance connect estaba pensado para conectarse a instancias EC2 con una dirección IP pública. En Junio de 2023, AWS lanzó una actualización de este servicio, permitiendo a los usuarios conectarse a las instancias EC2 con IP Privada a través de internet.
Para realizar esta tarea, se crea un EC2 Instance Connect Endpoint en la subnet privada de tu VPC. Este endpoint actúa como un túnel privado que te conecta desde Internet con las instancias privadas.
Es posible conectarse a diferentes subredes dentro de la VPC utilizando el mismo endpoint.
(Si la conexión es a una instancia en una AZ diferente del Endpoint, pueden aplicarse algunos cargos por transferencia de datos)
Aquí se puede encontrar una guía sobre cómo conectarse utilizando el EIC Endpoint a una instancia privada que usa IPv4.
Ventajas:
- Es posible conectarte a las instancias desde Internet sin un gateway.
- El acceso para crear y utilizar los endpoints para realizar la conexión puede restringirse/permitirse a través de políticas y permisos de IAM.
- Mejora la seguridad ya que se tiene un control de acceso centralizado a las instancias EC2 y se elimina la necesidad de gestionar las claves SSH.
- Se elimina la necesidad de un Bastion host.
- CloudTrail rastrea todos los eventos.
Desventajas:
- No soporta direcciones IPv6.
Migrar a IPv6
Desde 2011, AWS ha estado promoviendo IPv6; cada año, Amazon ha ido añadiendo y adaptando más servicios para utilizar esta tecnología.
Modos de compatibilidad de red soportados por AWS:
- Solo IPv4: Los recursos pueden comunicarse a través de IPv4; si se comunican con IPv6, requerirá una capa de interoperabilidad.
- Solo IPv6: Los recursos pueden comunicarse a través de IPv6; si se comunican con IPv6, se requerirá una capa de interoperabilidad.
- Dual- stack: Los recursos pueden comunicarse a través de IPv4 e IPv6.
En este artículo se puede encontrar la lista de servicios que pueden utilizar IPv6.
Para más información sobre cómo diseñar una red IPv6, se puede seguir el manual de mejores prácticas.
Ventajas:
- Reduce costes al dejar de utilizar IPv4
- Elimina la necesidad de mecanismos de traducción (NAT), eliminando la sobrecarga de rendimiento de las traducciones, simplificando el enrutamiento de paquetes
- IPv6 añade más seguridad, utilizando IPsec como estándar
Desventajas:
- No todos los servicios soportan IPv6 _ Debe realizarse un análisis de la arquitectura antes de implementar/adaptar nada.
Top comments (0)