Preguntas frecuentes sobre Amazon VPC

No se cobran cargos adicionales por crear y utilizar lo que es la VPC en sí. Los cargos por uso de otros servicios de Amazon Web Services, incluidos Amazon EC2, se aplican según las tarifas publicadas para dichos recursos, incluidos los cargos por transferencia de datos. Si conecta la VPC al centro de datos corporativo por medio de la conexión opcional de VPN de hardware, los precios corresponden a las horas de conexión de VPN (la cantidad de tiempo que se tiene una conexión de VPN en estado "disponible"). Las horas de carga de datos parciales se cobran como horas completas. Los datos transferidos mediante conexiones de VPN se cobrarán según las tarifas estándar de transferencia de datos de AWS. Para consultar la información de precios de VPC-VPN, visite la sección de precios de la página del producto Amazon VPC.

Los cargos por uso de otros servicios de Amazon Web Services, incluidos Amazon EC2, se aplican según las tarifas publicadas para dichos recursos. No se cobran gastos por transferencia de datos al obtener acceso a Amazon Web Services, como Amazon S3, a través del puerto de enlace a internet de su VPC.

Si obtiene acceso a los recursos de AWS a través de la conexión de VPN, se le aplicarán cargos por transferencia de datos de Internet.

Puede conectar su Amazon VPC a:

• Internet (a través de una gateway de Internet)
• El centro de datos de su empresa mediante una conexión de VPN de sitio a sitio (a través de la gateway privada virtual)
• Internet y el centro de datos de su empresa (con una gateway de Internet y una gateway privada virtual)
• Otros servicios de AWS (mediante la gateway de Internet, NAT, gateway privada virtual o puntos de enlace de VPC)
• Otras Amazon VPC (interconexiones de VPC)

Amazon VPC permite crear una gateway de Internet. Esta gateway permite que las instancias de Amazon EC2 en la VPC obtengan acceso directamente a Internet. También puede usar una gateway de Internet de salida únicamente, que es una gateway con estado para brindar acceso de salida solo para el tráfico IPv6 desde la VPC a Internet.

No. Una gateway de Internet se escala horizontalmente, es redundante y tiene alta disponibilidad. No existen limitaciones de ancho de banda.

Puede usar direcciones IP públicas, incluidas direcciones IP elásticas (EIP) y direcciones únicas globales IPv6 (GUA), para brindar a las instancias en la VPC la capacidad de establecer directamente una comunicación saliente a Internet y recibir tráfico entrante no solicitado de Internet (por ejemplo, servidores web). También puede usar las soluciones de la siguiente pregunta.

Cualquier dirección IP asignada a una instancia o un servicio alojado en una VPC a la que se puede acceder a través de Internet se considera una dirección IP pública. Solo las direcciones IPv4 públicas, incluidas las direcciones IP elásticas (EIP) y la GUA IPv6, pueden enrutarse en Internet. Para hacerlo, antes deberá conectar la VPC a Internet y luego actualizar la tabla de enrutamiento para que sea accesible desde o hacia Internet.

Las instancias sin direcciones IP públicas pueden obtener acceso a Internet de dos maneras distintas:

1. Las instancias sin direcciones IP públicas pueden direccionar el tráfico mediante una gateway de NAT o una instancia NAT para obtener acceso a Internet. Estas instancias utilizan la dirección IP pública de la gateway de NAT o la instancia NAT para atravesar Internet. El portal NAT o la instancia NAT deja pasar las comunicaciones de salida, pero no permite que las máquinas de Internet inicien una conexión con las instancias con dirección privada.
2. Para las VPC que tienen una conexión de VPN de hardware o Direct Connect, las instancias pueden direccionar su tráfico de Internet por la gateway privada virtual hasta su centro de datos. Desde ahí, pueden obtener acceso a Internet por medio de los puntos de salida existentes y a través de los dispositivos de seguridad y monitorización que tenga instalados en la red.

Sí. Puede utilizar una VPN por software de terceros para crear una conexión de VPN de acceso remoto o de sitio a sitio con su VPC por medio del puerto de enlace a internet.

No. Cuando se utilizan direcciones IP públicas, todas las comunicaciones entre instancias y servicios alojados en AWS utilizan la red privada de AWS. Los paquetes que se originan en la red de AWS con un destino en la red de AWS permanecen en la red global de AWS, excepto el tráfico hacia o desde las regiones de AWS China.

Todos los datos que fluyen en la red global de AWS y que interconectan nuestros centros de datos y regiones se cifran de manera automática en la capa física antes dejar nuestras instalaciones protegidas. También existen capas adicionales de cifrado. Por ejemplo, todo el tráfico de las interconexiones entre regiones de las VPC y las conexiones Transport Layer Security (TLS) del cliente o entre servicios. 

Una conexión de AWS VPN de sitio a sitio conecta la VPC con el centro de datos. Amazon admite conexiones de VPN de seguridad de protocolo de Internet (IPSec). Los datos que se transfieren entre su VPC y su centro de datos se direccionan a través de una conexión de VPN cifrada para ayudar a mantener la confidencialidad y la integridad de los datos en tránsito. No se necesita una gateway de Internet para establecer una conexión de VPN de sitio a sitio.

Puede usar cualquier rango de direcciones IPv4, incluido RFC 1918 o los rangos de IP de direccionamiento público para el bloque de CIDR principal. Para los bloques de CIDR secundarios, se aplican determinadas restricciones. El acceso a los bloques IP de direccionamiento público es posible únicamente a través de la gateway privada virtual y no es posible por Internet a través de la gateway de Internet. AWS no anuncia en Internet los bloques de direcciones IP que son propiedad del cliente. Puede asignar hasta 5 bloques de CIDR de GUA IPv6 proporcionados por Amazon o BYOIP a una VPC si llama a la API correspondiente o mediante la consola de administración de AWS.

Puede asignar un único rango de direcciones IP con enrutamiento entre dominios sin clases (CIDR) como el bloque de CIDR principal cuando cree una VPC y puede agregar hasta cuatro (4) bloques de CIDR secundarios después de crear la VPC. El usuario dirige las subredes de una VPC desde estos rangos de CIDR. Tenga en cuenta que, aunque puede crear varias VPC con rangos de direcciones IP superpuestas, esto impedirá la conexión de dichas VPC a una red doméstica común por medio de la conexión VPN de hardware. Por este motivo, recomendamos utilizar rangos de direcciones IP que no se superpongan. Puede asignar hasta 5 bloques de CIDR de GUA IPv6 proporcionados por Amazon o BYOIP a su VPC.

A las VPC predeterminadas se les asigna un rango CIDR de 172.31.0.0/16. Las subredes predeterminadas dentro de una VPC predeterminada se asignan a bloques de red /20 dentro de un rango CIDR de VPC. 

Sí, puede traer sus direcciones IPv4 públicas y direcciones GUA IPv6 a AWS VPC y asignarlas estáticamente a subredes e instancias EC2. Para acceder a estas direcciones a través de Internet, tendrá que publicarlas en Internet a partir de su red en las instalaciones. También deberá direccionar el tráfico a través de estas direcciones entre su VPC y la red local con conexión AWS DX o AWS VPN. Puede direccionar el tráfico desde su VPC con la gateway privada virtual. De manera similar, puede direccionar el tráfico desde su red local de vuelta a su VPC con sus routers.

Actualmente, Amazon VPC admite cinco (5) rangos de direcciones IP, una (1) principal y cuatro (4) secundarias para IPv4. Cada uno de estos rangos puede tener un tamaño de entre /28 (en notación CIDR) y /16. Los intervalos de direcciones IP de su VPC no deben superponerse con los intervalos de direcciones IP de la red existente.

Para IPv6, la VPC tiene un tamaño fijo de /56 (en notación CIDR). Una VPC puede tener bloques CIDR de IPv4 e IPv6 asociados a ella.

Sí. Puede ampliar su VPC existente mediante la incorporación de cuatro (4) rangos de IP IPv4 (CIDR) a la VPC. Puede reducir la VPC mediante la eliminación de los bloques de CIDR secundarios que agregó a esta.   De igual modo, puede agregar hasta cinco (5) rangos de IP IPv6 (CIDR) a la VPC.  Puede reducir la VPC mediante la eliminación de dichos rangos adicionales.

En estos momentos, puede crear 200 subredes por VPC. Si quiere crear más, envíe un caso al centro de soporte.

El tamaño mínimo de una subred es /28 (o 14 direcciones IP) para IPv4. Las subredes no pueden ser mayores que la VPC en la que se crean.

Para IPv6, el tamaño de subred está definido para que sea /64. Solo un bloque de CIDR de IPv6 se puede asignar a una subred.

Amazon se reserva las cuatro (4) primeras direcciones IP y la última (1) dirección IP de cada subred para las redes de IP.

Cuando lanza una instancia de Amazon EC2 dentro de una subred que no es solo IPv6, puede especificar opcionalmente la dirección IPv4 privada principal para la instancia. Si no especifica la dirección IPv4 privada principal, AWS la direcciona automáticamente desde el rango de direcciones IPv4 que asigna a esa subred. Puede asignar direcciones IPv4 privadas secundarias cuando lanza una instancia, cuando crea una interfaz de red elástica o en cualquier momento después de que se haya lanzado la instancia o se haya creado la interfaz. En caso de que lance una instancia de Amazon EC2 dentro de una subred solo de IPv6, AWS la direcciona automáticamente desde el CIDR de GUA IPv6 proporcionado por Amazon de esa subred. La GUA de IPv6 de la instancia permanecerá privada a menos que los haga accesibles desde/hacia Internet con el grupo de seguridad, NACL y la configuración de tabla de enrutamiento correctos.

Para una instancia lanzada en una subred IPv4 o de doble pila, la dirección IPv4 privada principal se retiene durante la vida útil de la instancia o la interfaz. Las direcciones IPv4 privadas secundarias se pueden asignar, desasignar o mover entre interfaces o instancias en cualquier momento. Para una instancia lanzada en una subred de solo IPv6, la GUA IPv6 asignada, que también es la primera dirección IP en la interfaz de red principal de la instancia, se puede modificar al asociar una nueva GUA IPv6 y eliminar la GUA IPv6 existente en cualquier momento.

No. Una dirección IPv4 asignada a una instancia en ejecución solo puede ser utilizada nuevamente por otra instancia una vez que la instancia en ejecución original esté en un estado “terminated” (terminado). Sin embargo, la GUA de IPv6 asignada a una instancia en ejecución puede ser utilizada nuevamente por otra instancia después de que se elimine de la primera instancia.

No. Puede especificar la dirección IP de una instancia cada vez que lance la instancia.

Puede asignar cualquier dirección IP a su instancia siempre que esta:

• Forme parte del rango de direcciones IP de la subred asociada
• No esté reservada por Amazon para fines de redes de IP
• No está asignada actualmente a otra interfaz.

Sí. Puede asignar una o varias direcciones IP privadas secundarias a una interfaz de red elástica o a una instancia EC2 en Amazon VPC. El número de estas direcciones que puede asignar depende del tipo de instancia. Consulte la Guía del usuario de EC2 para obtener información adicional acerca del número de direcciones IP privadas secundarias que se pueden asignar por cada tipo de instancia.

Sí, pero solo se podrá obtener acceso a las direcciones IP elásticas desde Internet (no a través de la conexión de VPN). Cada dirección EIP debe asociarse a una única dirección IP privada en la instancia. Las direcciones EIP deberán utilizarse exclusivamente en instancias de subredes configuradas para direccionar el tráfico directamente a la gateway de Internet. Las EIP no se pueden utilizar con instancias de subredes configuradas para utilizar una instancia NAT con el fin de obtener acceso a Internet. Se aplica únicamente a IPv4. Actualmente, las VPC de Amazon no son compatibles con las EIP para IPv6.

Bring Your Own IP (BYOIP) permite a los clientes migrar la totalidad o parte de su espacio de direcciones IPv4 o IPv6 de direccionamiento público existentes a AWS para poder usarlo con los recursos de AWS. Los clientes seguirán poseyendo el rango IP. Los clientes pueden crear IP elásticas a partir del espacio de IPv4 que incorporan a AWS y usarlas con instancias de EC2, puertas de enlace NAT y Network Load Balancers. Los clientes también pueden asociar hasta 5 CIDR a una VPC desde el espacio IPv6 que incorporan a AWS. Los clientes continuarán teniendo acceso a las IP suministradas por Amazon y pueden elegir entre usar IP elásticas propias (BYOIP), suministradas por Amazon o ambas.

Beneficios de incorporar direcciones de IP propias a AWS:
Reputación de IP: muchos clientes consideran la reputación de sus IP un recurso estratégico y desean usar dichas IP en AWS con sus recursos. Por ejemplo, los clientes que conservan servicios como MTA de email saliente y cuentan con IP de alta reputación ahora pueden incorporar su espacio de IP y conservar su tasa de éxito de envío.

Lista blanca de clientes: BYOIP también permite a los clientes mover cargas de trabajo que dependen de listas blancas de direcciones IP a AWS sin necesidad de restablecer las listas blancas con nuevas direcciones IP.

Dependencias codificadas de forma rígida: varios clientes tienen IP codificadas de forma rígida en dispositivos o han incorporado dependencias de arquitectura en sus IP. BYOIP permite a los clientes realizar migraciones a AWS sin dificultades.

Regulación y conformidad: muchos clientes se ven obligados a usar determinadas IP por motivos vinculados con normativas y conformidad. Eso también se resuelve con BYOIP.

Política de redes IPv6 en las instalaciones: muchos clientes pueden direccionar solamente su IPv6 en su red en las instalaciones. Estos clientes están desbloqueados por BYOIP, ya que pueden asignar su propio rango IPv6 a la VPC y elegir si quieren direccionar a su red en las instalaciones mediante Internet o Direct Connect.

Cuando lanza una EIP de BYOIP, esta regresa al grupo de IP de BYOIP a partir del cual se asignó.

Consulte nuestra documentación de para obtener información sobre la disponibilidad de BYOIP.

Sí. Puede usar el prefijo de BYOIP con cualquier cantidad de VPC en la misma cuenta.

Puede incorporar un máximo de cinco rangos IP a su cuenta.

A través de BYOIP, el prefijo más específico de IPv4 que puede incorporar es un prefijo IPv4 /24 y un prefijo IPv6 /56. Si pretende hacer público el prefijo IPv6 en Internet, el prefijo más específico es un prefijo IPv6 /48.

Puede usar los prefijos registrados ARIN, RIPE y APNIC.

Momentáneamente, no aceptamos prefijos reasignados o redistribuidos. Los rangos IP deben ser un tipo de red de asignación o distribución directa.

Sí. Puede hacerlo desaprovisionando el prefijo BYOIP de la región actual y después aprovisionándolo en la nueva región.

IP Address Manager (IPAM) de Amazon VPC es un servicio administrado que facilita la planificación, el seguimiento y el monitoreo de las direcciones IP para las cargas de trabajo de AWS. Con IPAM, puede organizar fácilmente las direcciones IP en función de las necesidades de enrutamiento y seguridad, así como establecer normas empresariales sencillas para regir las asignaciones de direcciones IP. También puede automatizar la asignación de direcciones IP a las VPC, con lo que se elimina la necesidad de utilizar aplicaciones de planificación de direcciones IP basadas en hojas de cálculo o de creación propia, que pueden ser difíciles de mantener y pueden requerir mucho tiempo. IPAM proporciona una visión operativa unificada, que se puede utilizar como su única fuente de verdad, lo que le permite realizar de forma más eficiente las actividades rutinarias de administración de direcciones IP, como el seguimiento de la utilización de IP, la resolución de problemas y la auditoría, de forma mucho más rápida.

Debería utilizar IPAM para que la administración de direcciones IP sea más eficiente. Los mecanismos existentes que aprovechan hojas de cálculo o herramientas caseras requieren trabajo manual y son propensos a errores. Con IPAM, por ejemplo, podrá desplegar aplicaciones más rápidamente, ya que sus desarrolladores no tendrán que esperar a que el equipo central de administración de direcciones IP las asigne. También puede detectar direcciones IP solapadas y solucionarlas antes de que se produzca un corte en la red. Además, puede crear alarmas para que IPAM le notifique si los grupos de direcciones están a punto de agotarse o si los recursos no cumplen las reglas de asignación establecidas en un grupo. Estas son algunas de las muchas razones por las que debería utilizar IPAM.

AWS IPAM proporciona las siguientes características:
 

• Asignación de direcciones IP para redes a escala: IPAM puede automatizar las asignaciones de direcciones IP en cientos de cuentas y VPC basadas en reglas empresariales configurables.
   
• Supervisión del uso de IP a través de su red: IPAM puede supervisar las direcciones IP y le permite recibir alertas cuando detecta posibles problemas, como el agotamiento de direcciones IP que puede paralizar el crecimiento de la red o el solapamiento de direcciones IP que puede dar lugar a un enrutamiento erróneo.
   
• Solución de problemas en la red: IPAM puede ayudarle a identificar rápidamente si los problemas de conectividad se deben a una mala configuración de las direcciones IP o a otros problemas.
   
• Auditoría de direcciones IP: IPAM retiene automáticamente los datos de supervisiones de las direcciones IP (hasta un máximo de tres años). Puede utilizar estos datos históricos para realizar análisis y auditorías retrospectivos de su red.

A continuación, se enumeran los componentes clave de IPAM:

• Un ámbito es el contenedor de más alto nivel dentro de IPAM. Un IPAM contiene dos ámbitos por defecto. Cada ámbito representa el espacio IP de una única red. El ámbito privado está destinado a todos los espacios privados. El ámbito público está destinado a todo el espacio público. Los ámbitos permiten reutilizar direcciones IP en varias redes no conectadas sin que se produzcan solapamientos o conflictos de direcciones IP. Dentro de un ámbito, se crean los grupos de IPAM.
   
• Un grupo es una colección de rangos de direcciones IP contiguos (o CIDR). Los grupos de IPAM le permiten organizar sus direcciones IP en función de sus necesidades de enrutamiento y seguridad. Puede tener varios grupos dentro de un grupo de nivel superior. Por ejemplo, si tiene necesidades de enrutamiento y seguridad distintas para las aplicaciones de desarrollo y de producción, puede crear un grupo para cada una. Dentro de los grupos de IPAM, se asignan CIDR a los recursos de AWS.
• Una atribución es una asignación CIDR de un grupo de IPAM a otro recurso o grupo de IPAM. Cuando se crea una VPC y se elige un grupo de IPAM para el CIDR de la VPC, el CIDR se asigna desde el CIDR aprovisionado al grupo de IPAM. Puede monitorear y administrar la asignación con IPAM.

Sí. IPAM admite direcciones BYOIPv4 y BYOIPv6. BYOIP es una característica de EC2 que le permite traer direcciones IP de su propiedad a AWS. Con IPAM, puede aprovisionar y compartir directamente sus bloques de direcciones IP entre cuentas y organizaciones. Los clientes actuales de BYOIP que utilizan IPv4 pueden migrar sus grupos a IPAM para simplificar la gestión de IP.

Sí, Amazon proporciona bloques de CIDR IPv6 contiguos para la asignación de VPC. Los bloques de CIDR contiguos permiten agregar CIDR en una única entrada a través de componentes de redes y seguridad, como listas de control de acceso, tablas de enrutamiento, grupos de seguridad y firewalls. Puede aprovisionar CIDR de IPv6 de Amazon en un grupo de ámbito público y utilizar todas las características de IPAM para administrar y monitorear el uso de IP. La asignación de estos bloques de CIDR comienza en incrementos de /52, y se pueden solicitar bloques mayores. Por ejemplo, puede asignar /52 CIDR de Amazon y utilizar IPAM para compartir entre cuentas y crear VPC en esas cuentas.

No, los bloques de CIDR IPv6 contiguos proporcionados por Amazon solo se admiten actualmente en IPAM.

Puede compartir grupos de IPAM con otras cuentas de su organización de AWS utilizando AWS Resource Access Manager (RAM). También puede compartir grupos de IPAM con cuentas fuera de su organización de AWS principal. Por ejemplo, estas cuentas pueden representar otra línea de negocio de su empresa o un servicio administrado presentado por un socio en su nombre, en otra organización de AWS.

Sí. Puede crear una ruta predeterminada para cada subred. La ruta predeterminada puede dirigir el tráfico para que salga de la VPC a través del puerto de enlace a internet, la gateway privada virtual o la instancia de NAT.

Es posible utilizar grupos de seguridad de Amazon EC2 para ayudar a proteger las instancias incluidas en Amazon VPC. Los grupos de seguridad de una VPC permiten especificar qué tráfico de red de entrada y de salida está autorizado en cada instancia de Amazon EC2. El tráfico que no esté específicamente autorizado a entrar o salir de una instancia queda automáticamente denegado.

Además de los grupos de seguridad, el tráfico de red que entra en cada subred y sale de ella puede autorizarse o denegarse por medio de listas de control de acceso (ACL) de la red.

Los grupos de seguridad de una VPC especifican qué tráfico está autorizado a entrar o salir de una instancia de Amazon EC2. Las ACL de red operan en el nivel de subred y evalúan el tráfico que entra y sale de una subred. Las ACL de red pueden utilizarse tanto para reglas Allow (permitir) como para reglas Deny (denegar). Las ACL de red no filtran el tráfico entre instancias situadas en una misma subred. Además, las ACL de red realizan filtrado sin información de estado, mientras que los grupos de seguridad sí incluyen información de estado.

Los filtros con información de estado realizan el seguimiento del origen de una solicitud y pueden permitir automáticamente que la respuesta a la solicitud vuelva al equipo que la generó. Por ejemplo, un filtro con información de estado que permita el tráfico entrante en el puerto TCP 80 en un servidor web permitirá que el tráfico de vuelta, normalmente en un puerto de número elevado (por ejemplo, el puerto TCP de destino 63 912), atraviese el filtro con información de estado situado entre el cliente y el servidor web. El dispositivo de filtrado mantiene una tabla de estado que realiza el seguimiento de los números de los puertos de origen y de destino, así como de las direcciones IP. Hace falta una única regla en el dispositivo de filtrado: permitir el tráfico entrante al servidor web a través del puerto TCP 80.

Por otra parte, el filtrado sin estado solamente examina la dirección IP de origen o de destino y el puerto de destino, sin tener en cuenta si el tráfico es una solicitud nueva o la respuesta a una solicitud. En el ejemplo anterior, sería necesario implementar dos reglas en el dispositivo de filtrado: una para permitir la entrada de tráfico al servidor web en el puerto TCP 80 y otra para permitir la salida de tráfico desde el servidor web (rango de puertos TCP del 49, 152 al 65, 535).

Sí. Si se ha configurado una gateway de Internet, el tráfico de Amazon VPC que se dirija a instancias de Amazon EC2 que no estén dentro de una VPC atravesará la gateway de Internet y entrará a la red pública de AWS para llegar hasta la instancia EC2. Si no se ha configurado un puerto de enlace a internet, o si la instancia está en una subred configurada para dirigirse a través de la gateway privada virtual, el tráfico atraviesa la conexión de VPN, sale del centro de datos y luego vuelve a entrar en la red pública de AWS.

Sí. Las instancias de una región se pueden comunicar entre sí con interconexiones VPC entre regiones, direcciones IP públicas, gateway de NAT, instancias NAT, conexiones de VPN o conexiones de Direct Connect.

Sí. Si la VPC está conectada a Internet, sus instancias pueden comunicarse con Amazon S3. Puede utilizar el punto de enlace de la VPC para S3, que se asegura de que todo el tráfico permanezca dentro de la red de Amazon y le permite aplicar políticas de acceso adicionales a su tráfico de Amazon S3. Puede utilizar la gateway de Internet para habilitar el acceso a Internet desde su VPC y que las instancias de la VPC puedan comunicarse con Amazon S3. También puede indicar que todo el tráfico a Amazon S3 atraviese Direct Connect o la conexión de VPN, salga del centro de datos y luego vuelva a entrar en la red pública de AWS.

Sí. Puede usar características de replicación de tráfico de Amazon VPC y de registros de flujos de Amazon VPC para monitorizar el tráfico de red en su Amazon VPC.

Los registros de flujo de la VPC es una función que le permite capturar información sobre el tráfico IP que va hacia y desde las interfaces de red en su VPC. Los datos de los registros de flujo pueden publicarse en Amazon CloudWatch Logs o en Amazon S3. Puede monitorear los registros de flujo de la VPC para obtener una visibilidad operativa de las dependencias de red y los patrones de tráfico; detectar anomalías y evitar filtraciones de datos; y, solucionar problemas de configuración y conectividad de la red. Los metadatos enriquecidos de los registros de flujo ayudan a adquirir información adicional sobre quién inició las conexiones TCP, así como el destino y el origen reales a nivel de paquete para el tráfico que fluye a través de capas intermedias, como la gateway de NAT. También puede archivar los registros de flujo para cumplir ciertos requisitos de conformidad. Para obtener más información sobre los registros de flujo de Amazon VPC, consulte la documentación.

Puede crear un registro de flujo para una VPC, una subred o una interfaz de red. Si se crea un registro de flujo para una subred o VPC, se supervisa cada interfaz de red de esa subred o VPC. Al crear una suscripción de registro de flujo, puede elegir los campos de metadatos que desea capturar, el intervalo de agregación máximo y el destino de registro preferido. También puede elegir capturar todo el tráfico o solo el tráfico aceptado o rechazado. Puede utilizar herramientas como CloudWatch Log Insights o CloudWatch Contributor Insights para analizar los registros de flujo de su VPC entregados a CloudWatch Logs. Puede utilizar herramientas como Amazon Athena o AWS QuickSight para consultar y visualizar los logs de flujo de su VPC entregados a Amazon S3. También puede crear una aplicación descendente personalizada para analizar sus registros o utilizar soluciones de socios como Splunk, Datadog, Sumo Logic, Cisco StealthWatch, Checkpoint CloudGuard, New Relic, etc.

Sí, puede crear un registro de flujo de VPC para una puerta de enlace de tránsito o para una conexión de puerta de enlace de tránsito individual. Con esta característica, Transit Gateway puede exportar información detallada como direcciones IP de origen/destino, puertos, protocolos, conteo de tráfico, marcas de tiempo y metadatos de los flujos de red que atraviesan Transit Gateway. Para obtener más información sobre la compatibilidad de los registros de flujo de Amazon VPC con Transit Gateway, consulte la documentación.

Los datos del registro de flujo se recogen fuera de la ruta de su tráfico de red y, por lo tanto, no afectan al rendimiento o la latencia de la red. Puede crear o eliminar registros de flujo sin riesgo de afectar el rendimiento de la red.

Los cargos por ingestión y archivo de datos para los registros vendidos se aplican cuando se publican registros de flujo en CloudWatch Logs o en Amazon S3. Para obtener más información y ejemplos, consulte los precios de Amazon CloudWatch. También puede hacer un seguimiento de los cargos a partir de la publicación de los registros de flujos mediante etiquetas de imputación de costos.

La replicación de tráfico de Amazon VPC facilita a los clientes la tarea de duplicar tráfico de red con destino y origen en una instancia de Amazon EC2 y de reenviarlo a dispositivos de monitorización y seguridad fuera de banda para casos de uso como inspección de contenido, monitorización de amenazas y resolución de problemas. Estos dispositivos se pueden implementar en una instancia EC2 individual o en una flota de instancias detrás de un balanceador de carga de red (NLB) con un agente de escucha de protocolo de datagramas de usuario (UDP).

La replicación de tráfico admite capturas de paquetes de red en la interfaz de red elástica (ENI) para instancias de EC2. Consulte la documentación sobre Creación de reflejo de tráfico para ver las instancias de EC2 que admiten la Creación de reflejo de tráfico de Amazon VPC.

Los clientes pueden utilizar herramientas de código abierto o elegir una de las múltiples soluciones de monitorización disponibles en AWS Marketplace. La replicación de tráfico permite a los clientes transmitir tráfico replicado a cualquier agente o recopilador de paquetes de red o herramienta de análisis, sin necesidad de instalar agentes de proveedores específicos.

Los registros de flujos de Amazon VPC permiten a los clientes recopilar, almacenar y analizar registros de flujos de red. La información que se plasma en los registros de flujos incluye datos acerca del tráfico permitido o denegado, direcciones IP de origen y destino, puertos, número de protocolo, número de bytes y paquetes y una acción (aceptar o rechazar). Puede usar esta característica para resolver problemas de conectividad y seguridad y para garantizar que las reglas de acceso a la red estén funcionando de la manera esperada.

La replicación de tráfico de Amazon VPC ofrece información más completa sobre el tráfico de la red, ya que le permite analizar el contenido real del tráfico, incluida la carga, y está destinada a casos de uso en los que se necesita analizar los paquetes reales para determinar la causa raíz de un problema de rendimiento, implementar ingeniería inversa en un ataque de red sofisticado o detectar y detener una infracción interna o cargas de trabajo en riesgo.

Amazon VPC está disponible actualmente en distintas zonas de disponibilidad en todas las regiones de Amazon EC2.

Sí. 

No. Una subred tiene que residir en una única zona de disponibilidad.

Cuando lance una instancia de Amazon EC2, deberá especificar en qué subred se debe lanzar dicha instancia. La instancia se lanzará en la zona de disponibilidad asociada a la subred especificada.

Cuando se crea una subred, es necesario especificar en qué zona de disponibilidad desea colocarla. Al utilizar el asistente de VPC, puede seleccionar la zona de disponibilidad de la subred en la pantalla de confirmación del asistente. Cuando se utiliza la API o la CLI, es posible especificar la zona de disponibilidad de la subred en el momento de crear la subred. Si no especifica una zona de disponibilidad, se seleccionará la opción predeterminada “No Preference” y se creará la subred en una zona de disponibilidad que esté disponible en la región.

Si las instancias residen en subredes situadas en zonas de disponibilidad diferentes, se le facturará 0,01 USD por cada GB de transferencia de datos.

Sí. DescribeInstances() devolverá todas las instancias de Amazon EC2 activas. Puede diferenciar las instancias EC2-Classic de las instancias EC2-VPC por una entrada en el campo de la subred. Si hay un ID de subred en la lista, la instancia está en una VPC.

Sí. DescribeVolumes() devolverá todos sus volúmenes EBS.

Para las instancias que requieren direccionamiento IPv4, puede ejecutar cualquier número de instancias de Amazon EC2 dentro de una VPC, siempre que esta tenga el tamaño adecuado para tener una dirección IPv4 asignada a cada instancia. Inicialmente, solo puede lanzar 20 instancias de Amazon EC2 a la vez, con un tamaño máximo de VPC de /16 (65 536 IP). Si quiere aumentar estos límites, complete el siguiente formulario. Para instancias solo de IPv6, el tamaño de VPC de /56 le brinda la capacidad de lanzar un número virtualmente ilimitado de instancias de Amazon EC2.

Puede utilizar las AMI en Amazon VPC si están registradas en la misma región que su VPC. Por ejemplo, puede utilizar las AMI registradas en us-east-1 con una VPC en us-east-1. Hay más información disponible en las preguntas frecuentes sobre regiones y zonas de disponibilidad de Amazon EC2.

Sí, puede utilizar las instantáneas de Amazon EBS si se encuentran en la misma región que su VPC. Hay más información disponible en las preguntas frecuentes sobre regiones y zonas de disponibilidad de Amazon EC2.

Sí, pero una instancia lanzada en VPC que utiliza una AMI de Amazon con respaldo EBS mantiene la misma dirección IP cuando se detiene y se reinicia. Esta situación se diferencia de las instancias similares lanzadas fuera de una VPC, que reciben una nueva dirección IP. Las direcciones IP para las instancias detenidas en una subred se consideran no disponibles.

Sí.

Sí. 

Sí. Amazon VPC admite instancias en clúster. No obstante, no todos los tipos de instancia están disponibles en todas las regiones y zonas de disponibilidad.

Cuando lanza una instancia, se le asigna un nombre de host. Hay dos opciones disponibles, un nombre basado en IP o un nombre basado en recursos, y este parámetro se puede configurar en el lanzamiento de la instancia. El nombre basado en IP usa una forma de la dirección IPv4 privada, mientras que el nombre basado en recursos usa una forma de ID de instancia.

Sí, puede cambiar el nombre de host de un formulario de instancia basado en IP a basado en recursos o viceversa deteniendo la instancia y luego cambiando las opciones de nomenclatura basadas en recursos.

Sí, el nombre de host de la instancia se puede utilizar como nombres de host DNS. Para las instancias lanzadas en una subred de pila doble o solo IPv4, el nombre basado en IP siempre se resuelve en la dirección IPv4 privada en la interfaz de red principal de la instancia y esto no se puede desactivar. Además, el nombre basado en recursos se puede configurar para que se resuelva en la dirección IPv4 privada en la interfaz de red principal, en la primera GUA de IPv6 en la interfaz de red principal, o en ambas. Para las instancias lanzadas en una subred de solo IPv6, el nombre basado en recursos se configurará para resolverse en la primera GUA de IPv6 en la interfaz de red principal. 

Una VPC predeterminada es una red virtual aislada de forma lógica en la nube de AWS que se crea automáticamente para su cuenta de AWS la primera vez que aprovisiona los recursos de Amazon EC2. Al lanzar una instancia sin especificar un ID de subred, la instancia se lanzará en su VPC predeterminada.

Cuando lanza recursos en una VPC predeterminada, puede beneficiarse de las funcionalidades de redes avanzadas de Amazon VPC (EC2-VPC) con la facilidad de uso de Amazon EC2 (EC2-Classic). Obtiene características como el cambio del grupo de seguridad sobre la marcha, el filtrado de salida del grupo de seguridad, varias direcciones IP y varias interfaces de red sin tener que crear explícitamente una VPC y lanzar instancias en la VPC.

Si su cuenta de AWS se creó después del 18 de marzo de 2013, es posible que pueda lanzar recursos en una VPC predeterminada. Consulte este anuncio en el foro para determinar las regiones habilitadas para el conjunto de características de la VPC predeterminada. Además, las cuentas creadas antes de las fechas mostradas pueden utilizar VPC predeterminadas en cualquier región habilitada para VPC predeterminada en la que no haya lanzado previamente instancias EC2 o aprovisionado recursos de Amazon Elastic Load Balancing, Amazon RDS, Amazon ElastiCache o Amazon Redshift.

No. Puede utilizar la consola de administración de AWS, la interfaz de línea de comandos (CLI) de AWS EC2 o la API de Amazon EC2 para lanzar y administrar las instancias EC2 y otros recursos de AWS en la VPC predeterminada. AWS creará automáticamente una VPC y una subred predeterminadas en cada zona de disponibilidad de la región de AWS. La VPC predeterminada se conecta a un puerto de enlace a internet y las instancias reciben automáticamente direcciones IP públicas, como la versión clásica de EC2.

Consulte las diferencias entre EC2-Classic y EC2-VPC en la guía del usuario de EC2.

No. Las VPC predeterminadas se agregan a Internet y todas las instancias lanzadas en las subredes predeterminadas de la VPC predeterminada reciben automáticamente las direcciones IP públicas. Puede añadir una conexión de VPN a su VPC predeterminada si lo desea.

Sí. Para lanzar una instancia en VPC no predeterminadas, debe especificar un ID de subred durante el lanzamiento de la instancia.

Sí. Para lanzar en subredes no predeterminadas, puede dirigir los lanzamientos usando la consola o mediante la opción --subnet desde la CLI, la API o el SDK.

Puede disponer de una VPC predeterminada en cada región de AWS donde el atributo Supported Platforms esté establecido en "EC2-VPC".

Se crea una subred predeterminada para cada zona de disponibilidad en su VPC predeterminada.

Por ahora no.

Por ahora no.

Sí, puede eliminar una VPC predeterminada. Una vez eliminada, puede crear una nueva VPC predeterminada directamente desde la consola de VPC o mediante la CLI. De esta manera, se creará una nueva VPC predeterminada en la región. Este proceso no recupera la VPC anterior que se eliminó.

Sí, puede eliminar una subred predeterminada. Una vez eliminada, puede crear una nueva subred predeterminada en la zona de disponibilidad con la CLI o el SDK. De esta manera, se creará una nueva subred predeterminada en la zona de disponibilidad especificada. Este proceso no recupera la subred anterior que se eliminó.

La manera más sencilla de obtener una VPC predeterminada es crear una nueva cuenta en una región habilitada para VPC predeterminadas o utilizar una cuenta existente en una región en la que nunca haya estado, siempre que el atributo Supported Platforms para la cuenta en dicha región se haya establecido en “EC2-VPC”.

Sí, pero solo podemos activar una VPC predeterminada en una cuenta existente si no dispone de recursos de EC2-Classic en esa región. Además, debe finalizar todos los recursos de Elastic Load Balancer, Amazon RDS, Amazon ElastiCache y Amazon Redshift no aprovisionados por la VPC en esa región. Tras la configuración de la cuenta para una VPC predeterminada, todos los lanzamientos de recursos futuros, incluidas las instancias lanzadas a través de Auto Scaling, se colocarán en la VPC predeterminada. Para solicitar que su cuenta existente se configure con una VPC predeterminada, vaya a Account and Billing (Cuenta y facturación) -> Service: Account (Servicio: cuenta) -> Category: Convert EC2 Classic to VPC (Categoría: convertir EC2 Classic a VPC) y realice una solicitud. Revisaremos su solicitud, sus servicios de AWS existentes y la presencia de EC2-Classic. A continuación, lo guiaremos en los siguientes pasos.

Si su cuenta de AWS dispone de una VPC predeterminada, cualquier cuenta de IAM asociada con su cuenta de AWS utilizará la misma VPC predeterminada que su cuenta de AWS.

EC2-Classic es una red plana que lanzamos con EC2 en el verano de 2006. Con EC2-Classic, sus instancias se ejecutan en una única red plana que comparte con otros clientes. Con el tiempo, inspirados por las necesidades cambiantes de nuestros clientes, lanzamos Amazon Virtual Private Cloud (VPC) en 2009 para permitirle ejecutar instancias en una nube virtual privada que está aislada de forma lógica de su cuenta de AWS. En la actualidad, aunque la mayoría de nuestros clientes utilizan Amazon VPC, tenemos algunos clientes que todavía utilizan EC2-Classic.

Vamos a retirar Amazon EC2-Classic el 15 de agosto de 2022 y es necesario que migre cualquier instancia EC2 y otros recursos de AWS que se ejecuten en EC2-Classic a Amazon VPC antes de esta fecha. La siguiente sección proporciona más información sobre la retirada de EC2-Class, así como herramientas y recursos para ayudar durante la migración.

Este cambio solo le afecta si tiene habilitado EC2-Classic en su cuenta en cualquiera de las regiones de AWS. Puede utilizar la consola o el comando describe-account-attributes para verificar si se ha habilitado EC2-Classic en una región de AWS. Consulte este documento para obtener más detalles.

Si no tiene ningún recurso de AWS activo que se ejecute en EC2-Classic en alguna región, desactive EC2-Classic en su cuenta para esa región. La desactivación de EC2-Classic en una región le permite lanzar allí la VPC predeterminada. Para ello, vaya a AWS Support Center en console.thinkwithwp.com/support, elija “Crear caso” y luego “Soporte de facturación y cuenta”, para “Tipo elija” “Cuenta”, para “Categoría” elija “Convertir EC2 Classic a VPC”, rellene los demás datos según sea necesario, y elija “Enviar”.

Desactivaremos automáticamente EC2-Classic de su cuenta el 30 de octubre de 2021 en cualquier región de AWS en la que no haya tenido ningún recurso de AWS (instancias EC2, base de datos relacional de Amazon, AWS Elastic Beanstalk, Amazon Redshift, AWS Data Pipeline, Amazon EMR, AWS OpsWorks) en EC2-Classic desde el 1 de enero de 2021.

Por otro lado, si tiene recursos de AWS que se ejecutan en EC2-Classic, planifique la migración a Amazon VPC lo antes posible. No podrá lanzar ninguna instancia o servicio de AWS en la plataforma de EC2-Classic después del 15 de agosto de 2022. Las cargas de trabajo o servicios en estado de ejecución perderán gradualmente el acceso a todos los servicios de AWS en EC2-Classic a medida que los retiremos a partir del 16 de agosto de 2022.

Puede encontrar las guías de migración de los recursos de AWS en la pregunta siguiente.

Amazon VPC le ofrece un control completo sobre su entorno de red virtual en AWS, aislado de forma lógica de su cuenta de AWS. En el entorno de EC2-Classic, las cargas de trabajo comparten una única red plana con otros clientes. El entorno de Amazon VPC ofrece muchas otras ventajas sobre el entorno de EC2-Classic, como la posibilidad de seleccionar su propio espacio de dirección IP, la configuración de subredes públicas y privadas y la administración de tablas de enrutamiento y gateways de red. Los servicios e instancias disponibles actualmente en EC2-Classic cuentan con servicios comparables en el entorno de Amazon VPC. Amazon VPC también ofrece una generación de instancias mucho más amplia y reciente que EC2-Classic. Obtenga más información sobre Amazon VPC en este enlace.

Para ayudar a migrar sus recursos, hemos publicado manuales y creado soluciones que encontrará a continuación. Para migrar, debe volver a crear los recursos EC2-Classic en la VPC. En primer lugar, puede utilizar este script para identificar todos los recursos aprovisionados en EC2-Classic en todas las regiones de una cuenta. Luego, puede utilizar la guía de migración de los recursos de AWS relevantes a continuación:

• Grupos de seguridad e instancias
• Equilibrador de carga clásico
• Amazon Relational Database Service
• AWS Elastic Beanstalk
• Amazon Redshift para la migración de clúster de DC1 y para otros tipos de nodos
• AWS Data Pipeline 
• Amazon EMR 
• AWS OpsWorks

Además de las guías de migración mencionadas, también ofrecemos una solución altamente automatizada de lift-and-shift (volver a alojar), AWS Application Migration Service (AWS MGN), que simplifica, agiliza y reduce el costo de la migración de aplicaciones. Puede encontrar recursos relevantes sobre AWS MGN aquí:

• Introducción al servicio de migración de aplicaciones de AWS 
• Formación técnica bajo demanda de AWS Application Migration Service
• Documentación para conocer a fondo las características y funcionalidades de AWS Application Migration Service
• Video de arquitectura de servicios y arquitectura de redes

En el caso de migraciones sencillas de instancias EC2 individuales desde EC2-Classic a VPC, además de AWS MGN o la guía de migración de instancias, también puede utilizar el runbook “AWSSupport-MigrateEC2 ClassicToVPC” en “AWS Systems Manager > Automation”. El runbook automatiza los pasos necesarios para migrar una instancia de EC2-Classic a VPC mediante la creación de una AMI de la instancia en EC2-Classic, la creación de una nueva instancia desde la AMI en VPC y, de forma opcional, la terminación de la instancia de EC2-Classic.

Si tiene alguna pregunta o duda, puede contactar al equipo de AWS Support a través de AWS Premium Support.

Nota: Si tiene recursos de AWS que se ejecutan en EC2-Classic en varias regiones de AWS, le recomendamos que desactive EC2-Classic en cada una de esas regiones en cuanto haya migrado los recursos que tenga en ellas a VPC.

Adoptaremos las dos medidas siguientes antes de la fecha de retirada del 15 de agosto de 2022:

• El 30 de octubre de 2021, dejaremos de emitir instancias reservadas (RI) de 3 años y RI de 1 año para el entorno EC2-Classic. Las IR que ya estén en el entorno de EC2-Classic no se verán afectadas en esta ocasión. Las IR que venzan después del 15/8/2022 tendrán que modificarse para utilizar el entorno de Amazon VPC durante el periodo restante del arrendamiento. Para obtener información sobre cómo modificar sus RI, consulte nuestro documento.
• El 15 de agosto de 2022, ya no permitiremos la creación de nuevas instancias (spot o bajo demanda) u otros servicios de AWS en el entorno de EC2-Classic. Las cargas de trabajo o servicios en estado de ejecución perderán gradualmente el acceso a todos los servicios de AWS en EC2-Classic a medida que los retiremos a partir del 16 de agosto de 2022.

Sí.

Las interfaces de red solo se pueden conectar a instancias que residan en la misma zona de disponibilidad.

Las interfaces de la red solo se pueden conectar a instancias en las VCP de la misma cuenta.

Sí, aunque no es el caso de uso más adecuado para interfaces múltiples. Es preferible asignar direcciones IP privadas adicionales a la instancia y, a continuación, asociar direcciones IP elásticas a las IP privadas, según proceda.

No. Puede conectar y desconectar las interfaces secundarias (eth1-ethn) de una instancia EC2, pero no puede desconectar la interfaz eth0.

Sí. Las interconexiones se pueden crear con VPC en diferentes regiones. Las interconexiones entre VPC ubicadas en distintas regiones están disponibles en todo el mundo en todas las regiones comerciales (excepto China).

Sí, siempre y cuando el propietario de la otra VPC acepte la solicitud de interconexión.

No se aplican cargos por crear interconexiones de VPC; no obstante, sí se aplican cargos por transferir datos entre interconexiones. Consulte la sección sobre transferencia de datos de la página Precios de EC2 para obtener acceso a las tarifas de transferencia de datos.

No. Las interconexiones de VPC no requieren una gateway de Internet.

No. El tráfico entre instancias en VPC interconectadas aún es privado y está aislado, de forma similar al tráfico entre dos instancias en la misma VPC, que también es privado y está aislado.

No. Cada extremo de la interconexión puede terminar la interconexión en cualquier momento. Si se termina la interconexión, no habrá tráfico entre las dos VPC.

No. No se admiten las relaciones interconectadas transitivas.

AWS usa la infraestructura existente de una VPC para crear una interconexión de VPC; no es ni una gateway ni una conexión de VPN y tampoco se basa en una pieza independiente del hardware físico. No hay un único punto de error para la comunicación ni un cuello de botella de ancho de banda.

Las interconexiones de VPC entre regiones funcionan con la misma tecnología de escala horizontal, redundante y de alta disponibilidad con la que cuenta la VPC actualmente. El tráfico de las interconexiones de VPC entre regiones se transmite mediante la red central de AWS, que cuenta con redundancia incorporada y asignación dinámica de ancho de banda. No hay ningún punto de error para la comunicación.

Si se interrumpe una interconexión entre regiones, el tráfico no se direccionará mediante Internet.

El ancho de banda entre instancias en VPC interconectadas no difiere del ancho de banda entre instancias de la misma VPC. Nota: Un grupo de ubicación puede extender las VPC interconectadas. No obstante, no podrá obtener ancho de banda totalmente biseccional entre instancias en VPC interconectadas. Obtenga más información sobre los grupos de ubicación.

El tráfico se cifra con algoritmos AEAD (cifrado autenticado con datos asociados) modernos. La administración y correspondencia de claves están a cargo de AWS.

De manera predeterminada, una consulta para un nombre de host público de una instancia en una VPC interconectada en una región diferente se resolverá en una dirección IP pública. El DNS privado de Route 53 se puede resolver en una dirección IP privada con interconexión de VPC entre regiones.

No. No es posible hacer referencia a grupos de seguridad en una interconexión de VPC entre regiones.

Sí. La interconexión de VPC entre regiones es compatible con IPv6.

No. La interconexión de VPC entre regiones no se puede usar con EC2-ClassicLink.

ClassicLink de Amazon Virtual Private Cloud (VPC) permite que las instancias EC2 de la plataforma clásica de EC2 se comuniquen con instancias en una VPC con direcciones IP privadas. Para utilizar ClassicLink, actívelo para una VPC en su cuenta y asocie un grupo de seguridad desde esa VPC con una instancia EC2-Classic. Todas las normas de su grupo de seguridad de VPC se aplicarán a las comunicaciones entre instancias clásicas de EC2 e instancias en la VPC. 

No existen cargos adicionales por el uso de ClassicLink; sin embargo, se aplicarán los cargos existentes por las transferencias de datos entre zonas de disponibilidad. Para obtener más información, consulte la página de precios de EC2.

Para utilizar ClassicLink, primero debe activar al menos una VPC en su cuenta para ClassicLink. Después, debe asociar un grupo de seguridad desde la VPC a la instancia EC2-Classic deseada. La instancia clásica de EC2 ya está vinculada a la VPC y es miembro del grupo de seguridad seleccionado en la VPC. Su instancia clásica de EC2 no se puede vincular a más de una VPC a la vez.

La instancia EC2-Classic no se convierte en miembro de la VPC. Se convierte en miembro del grupo de seguridad de VPC que se asoció con la instancia. Todas las normas y las referencias al grupo de seguridad de VPC se aplican a la comunicación entre las instancias de la instancia clásica de EC2 y los recursos de la VPC.

No. El nombre de host de DNS público de EC2 no se resolverá en la dirección IP privada de la instancia EC2-VPC cuando se consulte desde una instancia EC2-Classic y viceversa.

Sí. ClassicLink no se puede activar para una VPC que tenga un enrutamiento entre dominios sin clases (CIDR) y que esté en el rango 10.0.0.0/8, con la excepción de 10.0.0.0/16 y 10.1.0.0/16. Además, ClassicLink no se puede activar para ninguna VPC que tenga una entrada de tabla de ruteo dirigida al espacio CIDR 10.0.0.0/8 para un destino que no sea "local".

El tráfico proveniente de una instancia EC2-Classic solo se puede direccionar a las direcciones IP privadas de la VPC. No se direccionarán a ningún destino fuera de la VPC, incluidos los destinos del puerto de enlace a internet, la gateway privada virtual o las VPC interconectadas.

ClassicLink no cambia el control de acceso definido para una instancia clásica de EC2 a través de sus grupos de seguridad existentes desde la plataforma clásica de EC2.

La conexión de ClassicLink no se conservará durante los ciclos de parada/inicio de la instancia EC2-Classic. La instancia EC2-Classic deberá volver a vincularse con una VPC después de su parada o inicio. Sin embargo, la conexión de ClassicLink se conservará durante los ciclos de reinicio de la instancia.

ClassicLink no permite que las normas de grupos de seguridad clásicos de EC2 hagan referencia a grupos de seguridad de VPC o viceversa.

AWS PrivateLink permite a los clientes obtener acceso a servicios alojados en AWS con alta disponibilidad y escalabilidad, al mismo tiempo que todo el tráfico de red se conserva dentro de la red de AWS. Los usuarios del servicio pueden usarlo para obtener acceso privado a los servicios con tecnología de PrivateLink desde su Amazon Virtual Private Cloud (VPC) o su entorno local, sin utilizar IP públicas y sin que el tráfico deba atravesar Internet. Los propietarios de servicios pueden registrar su Network Load Balancer en los servicios de PrivateLink y suministrar los servicios a otros clientes de AWS.

Como usuario del servicio, necesitará crear puntos de enlace de la VPC de tipo interfaz para los servicios con tecnología de PrivateLink. Estos puntos de enlace del servicio aparecerán como interfaces de redes elásticas (ENI) con IP privadas en sus VPC. Una vez creados estos puntos de conexión, todo el tráfico destinado a estas IP se direccionará de manera privada a los servicios de AWS correspondientes.

Como propietario del servicio, puede incorporar su servicio a AWS PrivateLink mediante la definición de un balanceador de carga de red (NLB) para poner su servicio al frente y crear un servicio de PrivateLink para registrar con el NLB. Sus clientes podrán definir puntos de conexión dentro de su VPC para conectarse a su servicio después de que usted haya incluido sus cuentas y funciones de IAM en una lista de elementos permitidos.

Los siguientes servicios de AWS admiten esta característica: Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB), Kinesis Streams, Service Catalog, EC2 Systems Manager, Amazon SNS y AWS DataSync. Muchas soluciones SaaS también admiten esta característica. Visite AWS Marketplace para buscar más productos SaaS con tecnología de AWS PrivateLink.

Sí. La aplicación de su entorno local se puede conectar a los puntos de enlace de servicios en Amazon VPC a través de AWS Direct Connect. Los puntos de conexión de los servicios direccionarán automáticamente el tráfico a los servicios de AWS con tecnología de AWS PrivateLink.

Sí. Puede utilizar la consola de administración de AWS para administrar objetos de Amazon VPC como VPC, subredes, tablas de ruteo, gateways de Internet y conexiones de VPN IPSec. Además, puede utilizar un sencillo asistente para crear una VPC.

Consulte la Guía del usuario de Amazon VPC para obtener información acerca de los límites de VPC.

Sí. Haga clic aquí para obtener más información sobre AWS Support.

Oficialmente, ya no se admite el uso de ElasticFox para administrar su Amazon VPC. La compatibilidad con Amazon VPC se consigue mediante API de AWS, herramientas de línea de comandos, consola de administración de AWS y distintas utilidades de terceros.