Redes, operaciones y precios

VPC es un servicio que permite lanzar recursos de AWS dentro de una red virtual (仮想ネットワーク) aislada lógicamente que uno mismo define, de modo que se puede construir en AWS una configuración muy parecida a una red tradicional del propio centro de datos. Entregar contenido desde ubicaciones de borde es tarea de CloudFront; proporcionar el registro de dominios, el enrutamiento DNS y las comprobaciones de estado es tarea de Route 53; y tender una conexión dedicada que evita los ISP de la ruta es tarea de Direct Connect.

Una subred (サブネット) es un rango de direcciones IP dentro de una VPC que siempre pertenece a una sola zona de disponibilidad (アベイラビリティゾーン). Por tanto, una subred no puede abarcar varias AZ, y distribuir entre varias AZ significa crear una subred por cada AZ. Decidir hacia dónde se dirige el tráfico es tarea de la tabla de enrutamiento, y la puerta de enlace hacia internet es la puerta de enlace de internet; ambos son componentes distintos de la subred.

Una tabla de enrutamiento (ルートテーブル) es una tabla que decide hacia dónde se dirige el tráfico de una subred o de una puerta de enlace. Delimitar el rango de direcciones IP es tarea de la subred, proporcionar la conexión a internet es tarea de la puerta de enlace de internet (インターネットゲートウェイ), y hacer de intermediario del tráfico saliente de los recursos con IP privadas es tarea de la puerta de enlace NAT (NATゲートウェイ). Las funciones de estos cuatro componentes no se solapan.

Una puerta de enlace NAT (NATゲートウェイ) es un mecanismo que permite que un recurso con una dirección IP privada acceda a internet sin dejar de ser privado. Como solo hace de intermediario del tráfico que sale desde dentro hacia fuera, a través de ella no se puede establecer una conexión entrante desde fuera. Una puerta de enlace de internet conecta la propia VPC a internet y no es un componente que se coloque dentro de una subred. Direct Connect es una conexión dedicada a una red on-premises y CloudFront es un servicio de entrega de contenido; ninguno de los dos se usa para este fin.

Route 53 es un servicio web de DNS de alta disponibilidad y escalable con tres funciones —registro de dominios (ドメイン登録), enrutamiento DNS (DNSルーティング) y comprobación de estado (ヘルスチェック)— que se pueden combinar como se necesite. La entrega de contenido es tarea de CloudFront, y distribuir el tráfico entrante es tarea de Elastic Load Balancing; ninguna de las dos es una función de Route 53.

CloudFront es una CDN que acelera la entrega de contenido web tanto estático como dinámico. A menudo se supone que solo entrega archivos estáticos, pero la descripción oficial incluye también el contenido dinámico. La entrega se realiza a través de una red mundial de centros de datos llamados ubicaciones de borde (エッジロケーション), desde la ubicación que tenga la menor latencia. Gestionar una conexión dedicada a una red on-premises es tarea de Direct Connect, no de CloudFront.

Direct Connect es un servicio que conecta una red on-premises con una ubicación de Direct Connect mediante un cable de fibra óptica Ethernet estándar, evitando los ISP de la ruta de red, y crea una interfaz virtual (仮想インターフェイス) directamente hacia los servicios de AWS. El punto clave es que se trata de una conexión dedicada (専用の接続) que no pasa por internet, y en eso se diferencia de un método que construye un túnel cifrado sobre internet.

Una tabla de enrutamiento es una tabla que decide hacia dónde se dirige el tráfico de una subred o de una puerta de enlace. Una subred cuya tabla de enrutamiento tiene una ruta hacia una puerta de enlace de internet se denomina habitualmente subred pública (パブリックサブネット), y una sin esa ruta, subred privada (プライベートサブネット). Una subred siempre pertenece a una sola AZ, así que el número de AZ no las distingue. Cuando un recurso de una subred privada sale hacia fuera, lo hace a través de una puerta de enlace NAT.

Un origen (オリジン) es el lugar que contiene la fuente del contenido que entrega CloudFront, como un bucket de S3 o un servidor HTTP. Cuando el contenido solicitado no está en la ubicación de borde, CloudFront lo obtiene del origen y lo entrega. Devolver el contenido desde el lugar más cercano al usuario es tarea de la ubicación de borde; la capa de caché intermedia entre una ubicación de borde y el origen es la caché de borde regional (リージョナルエッジキャッシュ); y dirigir a un destino en respuesta a una consulta de nombre es el enrutamiento DNS de Route 53.

Route 53 es un servicio web de DNS cuyas tres funciones —registro de dominios, enrutamiento DNS (DNSルーティング) y comprobación de estado (ヘルスチェック)— se pueden combinar como se necesite. No es un sistema en el que las tres deban estar presentes para funcionar, así que se puede dejar el dominio registrado en otro lugar y confiar a Route 53 solo el enrutamiento DNS, o usar solo la comprobación de estado. Transferir el dominio (移管) no es un requisito previo para usarlo.

ALB funciona en la capa 7, la capa de aplicación (アプリケーション層), y maneja HTTP, HTTPS y gRPC. Como examina hasta ese nivel, puede usar el contenido de HTTP como base para sus decisiones, lo que permite un enrutamiento flexible, como el enrutamiento basado en contenido (コンテンツベースルーティング). NLB funciona en la capa 4 (TCP, UDP, TLS), y Gateway Load Balancer funciona en las capas 3 y 4 (IP).

NLB es un balanceador de carga (ロードバランサ) de capa 4 que maneja TCP, UDP y TLS. Es la opción cuando se necesitan un rendimiento extremadamente alto y una dirección IP estática (静的IPアドレス). Manejar HTTP, HTTPS y gRPC es tarea del ALB de capa 7, y dejar pasar el tráfico IP de forma transparente sin terminar los flujos es tarea de Gateway Load Balancer. gRPC no figura en la lista de protocolos compatibles con NLB.

GWLB funciona en las capas 3 y 4 y maneja el protocolo IP. Es un mecanismo para colocar en la ruta del tráfico funciones de seguridad o de red basadas en dispositivos (アプライアンス), y la diferencia decisiva con los otros dos es que deja pasar los flujos de forma transparente (透過的) sin terminarlos (終端). Enrutar examinando el contenido de HTTP es el punto fuerte del ALB de capa 7, y una IP estática con UDP es el punto fuerte del NLB de capa 4.

Cuando se requiere una dirección IP estática (静的IPアドレス), se elige NLB. NLB funciona en la capa 4 y oficialmente se presenta como adecuado para escenarios que requieren un rendimiento extremadamente alto y una IP estática. ALB funciona en la capa 7, maneja HTTP, HTTPS y gRPC, y su punto fuerte es el enrutamiento basado en contenido. GWLB sirve para intercalar un dispositivo de forma transparente. Classic Load Balancer es una generación anterior que admite TCP, SSL/TLS, HTTP y HTTPS.

ELB distribuye automáticamente el tráfico entrante de las aplicaciones entre varios destinos (ターゲット) en una o más zonas de disponibilidad. No se limita a una sola AZ, y poder distribuir entre destinos repartidos en varias AZ es la base del diseño de disponibilidad (可用性設計). El registro de nombres de dominio es tarea de Route 53, y la entrega desde ubicaciones de borde es tarea de CloudFront.

Los protocolos (プロトコル) que maneja ALB son HTTP, HTTPS y gRPC, y funciona en la capa 7. De estas opciones, ALB es el único que puede manejar gRPC directamente. NLB es un balanceador de carga de capa 4 que maneja TCP, UDP y TLS, y GWLB es un balanceador de carga de capas 3 y 4 que maneja IP. Classic Load Balancer admite TCP, SSL/TLS, HTTP y HTTPS.

NLB es un balanceador de carga de capa 4 que maneja TCP, UDP y TLS, por lo que puede distribuir el tráfico UDP. Lo que maneja ALB es HTTP, HTTPS y gRPC, lo que no incluye UDP. GWLB maneja IP, pero está pensado para dejar pasar el tráfico de forma transparente hacia un dispositivo (アプライアンス), no para el balanceo de carga (負荷分散) de uso general. Classic Load Balancer admite TCP, SSL/TLS, HTTP y HTTPS.

ALB maneja HTTP, HTTPS y gRPC en la capa 7 (レイヤー7); NLB maneja TCP, UDP y TLS en la capa 4; y GWLB maneja IP en las capas 3 y 4. Para recordar el orden ayuda pensar que, cuanto mayor es el número de capa, más información de alto nivel es visible para las decisiones de enrutamiento. Solo GWLB abarca dos capas, debido a su naturaleza de dejar pasar los paquetes IP de forma transparente tal cual.

Enrutar según el contenido de HTTP, como la ruta o el nombre de host, se denomina enrutamiento basado en contenido (コンテンツベースルーティング) y es el punto fuerte de ALB, que funciona en la capa 7. NLB funciona en la capa 4, por lo que no ve el contenido de HTTP. GWLB deja pasar los flujos sin terminarlos, por lo que lo único disponible para las decisiones de enrutamiento es la IP. Classic Load Balancer, además, es un diseño de generación anterior; para este fin se elige ALB.

GWLB funciona en las capas 3 y 4, maneja el protocolo IP y es un balanceador de carga diseñado para funciones de seguridad o de red basadas en dispositivos (アプライアンス). Como deja pasar los flujos de forma transparente sin terminarlos (終端), intercalar un dispositivo de inspección (検査装置) en medio no cambia cómo se ve el tráfico. ALB y NLB están diseñados para recibir ellos mismos el tráfico y distribuirlo, no para dejarlo pasar de forma transparente. CloudFront es un servicio de entrega de contenido.

IAM es un servicio que controla de forma segura el acceso a los recursos de AWS y administra quién se autentica (認証, inicia sesión) y quién está autorizado (認可, tiene permisos). Crear y controlar claves es tarea de KMS, supervisar y controlar las solicitudes HTTP es tarea de WAF, y guardar y rotar credenciales y claves de API es tarea de Secrets Manager. Las funciones no se solapan.

IAM es un servicio que administra "quién se autentica (inicia sesión) y quién está autorizado (tiene permisos)". La autenticación (認証) es el paso de confirmar que uno es quien dice ser, y la autorización (認可) es el paso posterior que decide qué se permite hacer; difieren tanto en el orden como en la función. Aunque se pueda iniciar sesión, no se puede realizar una operación que la política (ポリシー) no permita. Memorizar ambos al revés lleva a interpretar mal el diseño de permisos.

KMS es un servicio administrado que facilita crear y controlar las claves que se usan para el cifrado y la firma, y una clave KMS está protegida por un HSM certificado según FIPS 140-3 nivel de seguridad 3. La clave nunca sale de KMS en estado no cifrado. Por tanto, no es posible exportarla ni distribuirla en texto plano (平文); en su lugar, las operaciones de cifrado (暗号化) y descifrado (復号) se solicitan a KMS.

WAF supervisa las solicitudes HTTP y HTTPS que se reenvían a un recurso de aplicación web protegido y controla el acceso mediante acciones como permitir (許可), bloquear (ブロック), contar (カウント) y CAPTCHA o desafío (チャレンジ). Como existe la acción de contar, se puede medir el impacto antes de convertir una regla en un bloqueo definitivo, en lugar de bloquear de inmediato. El cifrado y la firma corresponden a KMS, el registro y la visualización a CloudWatch, y el registro de dominios y la resolución de nombres a Route 53.

Shield proporciona protección contra ataques DDoS. Standard es una protección básica que se incluye automáticamente sin costo adicional con servicios como AWS WAF, y Advanced es una protección ampliada (拡張保護) disponible con un cargo adicional (追加料金). Advanced ofrece la mitigación automática de ataques DDoS de capa 7, visibilidad detallada y soporte dedicado del Shield Response Team (SRT). Tenga cuidado con la opción que invierte cuál de los dos tiene costo adicional.

Shield Advanced es una protección ampliada (拡張保護) con cargo adicional que ofrece la mitigación automática de ataques DDoS de capa 7, visibilidad detallada y soporte dedicado (専任のサポート) del Shield Response Team (SRT). La rotación es tarea de Secrets Manager, administrar de forma centralizada la protección en varias cuentas es tarea de AWS Firewall Manager, y un directorio de usuarios con emisión de tokens corresponde a los grupos de usuarios de Amazon Cognito.

Secrets Manager es un servicio que administra, obtiene y rota secretos (シークレット) —como credenciales de bases de datos, credenciales de aplicaciones, tokens OAuth y claves de API— a lo largo de todo su ciclo de vida. El inicio de sesión y la emisión de tokens es tarea de Cognito, registrar la configuración y evaluar el cumplimiento es tarea de AWS Config, y crear y proteger las propias claves es tarea de KMS. Ayuda recordar Secrets Manager como el que guarda y entrega los valores.

Un grupo de usuarios (ユーザープール) es un directorio de usuarios que autentica y autoriza a los usuarios para aplicaciones y API, y funciona como un proveedor de identidad OIDC independiente que emite tokens OAuth 2.0 y JWT. Un grupo de identidades (IDプール) concede a usuarios autenticados o no autenticados acceso a los recursos de AWS, y emite credenciales temporales de AWS (一時的なAWS認証情報) a través de AWS STS. Integrar ambos no es obligatorio para ninguno de los dos; cada uno puede usarse por separado.

Un grupo de identidades (IDプール) es un mecanismo que concede a usuarios autenticados o no autenticados acceso a los recursos de AWS, y emite credenciales temporales de AWS (一時的なAWS認証情報) a través de AWS STS. Lo que emite un grupo de usuarios son tokens OAuth 2.0 y JWT, que no son credenciales para llamar directamente a las API de AWS. Distribuir credenciales a largo plazo, o crear un usuario de IAM por cada usuario, no es adecuado para este fin.

Firewall Manager es un servicio que administra de forma centralizada (一元管理) protecciones —como AWS WAF, Shield Advanced, los grupos de seguridad y las ACL de red de la VPC, Network Firewall y Route 53 Resolver DNS Firewall— en varias cuentas y recursos. Inspeccionar las solicitudes individuales es tarea del propio WAF, crear claves es tarea de KMS, y gestionar la información de inicio de sesión es tarea de Cognito.

CloudWatch supervisa en tiempo real los recursos de AWS y las aplicaciones que se ejecutan en ellos, y visualiza el rendimiento, el estado operativo y el uso de los recursos mediante métricas (メトリクス), registros (ログ), alarmas (アラーム) y paneles (ダッシュボード). Registrar quién realizó qué operación de API es tarea de CloudTrail, registrar la configuración y sus cambios es tarea de AWS Config, y construir recursos a partir de plantillas es tarea de CloudFormation.

CloudTrail registra como eventos (イベント) las acciones realizadas por usuarios, roles y servicios de AWS. Abarca las operaciones realizadas a través de la consola de administración, la CLI y el SDK o la API, lo que permite rastrear después quién realizó qué operación de API. CloudWatch se encarga de la supervisión del rendimiento y el estado, CloudFormation de la construcción a partir de plantillas, y Systems Manager de las tareas operativas en los nodos; ninguno de ellos apunta a rastrear quién realizó una acción.

Config ofrece una vista detallada de la configuración de los recursos (構成) y registra las relaciones entre recursos y cómo estaban configurados en el pasado, para que se puedan rastrear los cambios de configuración. Además, evalúa la configuración con reglas de Config y marca como no conformes (非準拠) los recursos que las infringen. Supervisar umbrales es tarea de CloudWatch, construir a partir de plantillas es tarea de CloudFormation, y registrar operaciones es tarea de CloudTrail.

Ayuda memorizar los tres juntos: CloudWatch es la supervisión en tiempo real del rendimiento y el estado, CloudTrail es el registro de quién realizó qué operación de API, y Config es el registro de la configuración de los recursos y la evaluación del cumplimiento (準拠性). No son servicios que compitan entre sí: un registro de seguimiento (トレイル) de CloudTrail se guarda en un bucket de S3 y opcionalmente también puede entregarse a CloudWatch Logs, de modo que CloudTrail es el emisor y CloudWatch Logs un posible extremo receptor.

En CloudFormation, se crea una plantilla (テンプレート), un archivo de texto que describe los recursos necesarios, y CloudFormation aprovisiona y configura los recursos de acuerdo con ella. Los recursos creados pueden administrarse juntos como una sola unidad llamada pila (スタック), y también pueden eliminarse juntos. Así, la plantilla corresponde a un plano, y la pila al grupo de recursos resultante.

El grupo de recursos que crea CloudFormation puede administrarse como una sola unidad llamada pila (スタック), y también puede eliminarse de una sola vez. No es cierto que los recursos solo puedan manejarse de forma individual; al eliminar la pila se eliminan junto con ella los recursos que contiene. Registrar los cambios de configuración a lo largo del tiempo es función de AWS Config. Poder construir en conjunto y desmontar en conjunto es una ventaja de tratar la infraestructura como código (IaC).

Systems Manager es una interfaz unificada (統合インターフェイス) para ver, administrar y operar de forma centralizada y a gran escala los nodos (ノード) de entornos de AWS, on-premises y multinube, e incluye funciones como Run Command, Session Manager, Automation, Parameter Store, Patch Manager y Fleet Manager. Registrar la configuración es tarea de Config, construir a partir de plantillas es tarea de CloudFormation, y distribuir el tráfico es tarea de ELB.

Las instancias de spot (スポットインスタンス) son una opción de compra que usa la capacidad de EC2 no utilizada (未使用のキャパシティ) de la nube de AWS y que ofrece un descuento considerable, pero con la posibilidad de interrupción. Son adecuadas para procesamientos por lotes o entornos de prueba que toleren interrupciones. Comprometerse con un nivel de uso corresponde a Savings Plans, comprometerse con atributos de instancia corresponde a una instancia reservada (リザーブドインスタンス), y no tener pago inicial ni compromiso corresponde a On-Demand (オンデマンド).

Savings Plans es un modelo de precios que ofrece un descuento a cambio de comprometerse (コミット) con un nivel de uso determinado, mientras que una instancia reservada (リザーブドインスタンス) es un modelo de precios que ofrece un descuento a cambio de comprometerse con atributos como el tipo de instancia, la plataforma y la tenencia. Ambos tienen plazos de 1 o 3 años, y el pago puede elegirse entre pago inicial total, pago inicial parcial o sin pago inicial. Las que pueden interrumpirse son las instancias de spot.

Compute Savings Plans es el más flexible: admite cambios de familia de instancias (インスタンスファミリー), cambios de región (リージョン), el paso entre EC2, Fargate y Lambda, y cambios de sistema operativo. EC2 Instance Savings Plans se compromete con una familia de instancias específica en una región específica, por lo que, aunque se pueden cambiar el tamaño dentro de la familia y el sistema operativo, no se puede cambiar de familia ni de región. El plazo de ambos es de 1 o 3 años, y el pago puede elegirse entre pago inicial total, pago inicial parcial o sin pago inicial.