Principales servicios de AWS

EC2 es Amazon Elastic Compute Cloud y proporciona capacidad de cómputo redimensionable, es decir, servidores virtuales (仮想サーバー). S3 es Amazon Simple Storage Service y almacena cualquier cantidad de datos como objetos (オブジェクト). Intercambiar estos dos es una confusión frecuente desde hace mucho, por lo que conviene recordar la función a partir del nombre completo. Ejecutar código de funciones es la función de Lambda, y compartir archivos es la de EFS.

Lambda permite ejecutar código sin aprovisionar ni administrar servidores, y solo se factura el tiempo de cómputo que se consume (消費したコンピューティング時間). Mientras el código no se ejecuta no se genera ningún cargo, y esa es la diferencia clave con EC2, donde el costo se acumula mientras la instancia siga en funcionamiento. Ni el número de funciones ni el tamaño del código cargado son la unidad de facturación.

Sin servidor (サーバーレス) no significa que no exista un servidor físico, sino que el cliente no necesita aprovisionar, configurar ni escalar servidores. Lambda se describe como un servicio que permite "ejecutar código sin aprovisionar ni administrar servidores", y Fargate como un servicio que elimina la necesidad de "aprovisionar, configurar o escalar servidores o clústeres". El servidor físico existe del lado de AWS, y decidir el tipo de sistema operativo o la política de parches es propio de una modalidad como EC2.

Fargate es un motor de cómputo sin servidor y de pago por uso (従量課金) para contenedores (コンテナ), que elimina la necesidad de aprovisionar, configurar o escalar servidores o clústeres, y se usa como tipo de lanzamiento (起動タイプ) de ECS o EKS. La operación administrada de Kubernetes corresponde a EKS; elegir uno mismo el tipo y la cantidad de instancias es el tipo de lanzamiento EC2; y definir pasos como un flujo de trabajo corresponde a Step Functions.

Las opciones básicas de capacidad (キャパシティ) de ECS son Fargate, que es sin servidor y en el que AWS administra la infraestructura de cómputo subyacente (基盤), y EC2, en el que el cliente elige y administra el tipo y la cantidad de instancias. También existen ECS Managed Instances y, para entornos on-premises, ECS Anywhere. Sea cual sea la opción elegida, ECS es el servicio que coloca y escala los contenedores; lo único que cambia es quién se encarga de la infraestructura de cómputo subyacente.

EKS es Amazon Elastic Kubernetes Service, un servicio administrado (マネージドサービス) que permite ejecutar Kubernetes en AWS sin instalar ni operar por cuenta propia un clúster de Kubernetes, y cuenta con la certificación de conformidad con Kubernetes. Automatizar la operación de bases de datos es la función de RDS, entregar contenido desde una ubicación cercana es la de CloudFront, y distribuir el tráfico es la de Elastic Load Balancing.

Lambda permite ejecutar código sin administrar servidores, solo se factura el tiempo de cómputo consumido y no se cobra nada mientras no se ejecuta. Por eso, para un procesamiento que se invoca de forma esporádica, Lambda resulta ventajoso, ya que no se genera costo durante el tiempo de espera inactivo. Las configuraciones que mantienen en ejecución continua (常時稼働) una instancia EC2 o un clúster EKS generan costos durante los largos periodos en que no se está procesando nada.

EC2 se describe oficialmente como un servicio que proporciona capacidad de cómputo segura y redimensionable en la nube, en el que solo se paga por lo que se usa y se tiene control total sobre el recurso de cómputo (コンピューティングリソース). Que solo se facture el tiempo de ejecución y nunca se toque el sistema operativo describe a Lambda; almacenar datos como objetos describe a S3; y definir un flujo de trabajo como estados describe a Step Functions. Conviene tener presente, además, que la contrapartida de un control tan amplio es que la administración del sistema operativo sigue en manos del cliente.

ECS es Amazon Elastic Container Service, un servicio de orquestación de contenedores (コンテナオーケストレーション) totalmente administrado que facilita desplegar, administrar y escalar aplicaciones en contenedores. Proporcionar un clúster conforme con Kubernetes es la función de EKS, lanzar instancias de servidores virtuales es la de EC2, y ejecutar código en respuesta a eventos es la de Lambda. ECS y EKS agrupan contenedores, pero se diferencian en si usan Kubernetes o no.

EKS es un servicio administrado que permite ejecutar Kubernetes en AWS sin instalar ni operar por cuenta propia un clúster de Kubernetes, y cuenta con la certificación de conformidad con Kubernetes (Kubernetes 準拠). ECS, en cambio, es el servicio de orquestación de contenedores totalmente administrado propio de AWS, que no presupone Kubernetes. Ambos son servicios que trabajan con contenedores, no servicios limitados a imágenes de servidores virtuales. Además, ambos pueden usar Fargate como destino de ejecución.

EBS es un volumen de almacenamiento en bloques (ブロックストレージ) persistente para usar con instancias EC2, que se replica automáticamente dentro de una zona de disponibilidad (アベイラビリティゾーン) y que, en principio, se conecta a una sola instancia, que es la que lo usa. EFS es un sistema de archivos (ファイルシステム) para cargas de trabajo de Linux que crece y se reduce automáticamente y admite el acceso compartido en paralelo desde miles de instancias EC2. La capacidad de compartir es de EFS; no es cierto que ambos sirvan para compartir, ni que ambos sean exclusivamente para una sola conexión.

S3 es Amazon Simple Storage Service, un almacenamiento de objetos (オブジェクトストレージ) con excelente escalabilidad y disponibilidad, capaz de guardar y proteger cualquier cantidad de datos. El almacenamiento en bloques es EBS, el sistema de archivos compartido para Linux es EFS y la caché en memoria es ElastiCache. La diferencia entre estas tres formas de guardar los datos (objetos, bloques y archivos) es el punto de partida para elegir el almacenamiento de AWS.

EFS es un almacenamiento de archivos cuya capacidad crece y se reduce automáticamente según la cantidad de archivos y que admite el acceso compartido en paralelo (並列共有アクセス) desde miles de instancias EC2, por lo que se ajusta al caso de uso de montar (マウント) el mismo directorio desde muchas instancias a la vez. EBS es almacenamiento en bloques dentro de una zona de disponibilidad que, en principio, se conecta a una sola instancia, de modo que cada instancia tendría su propia área por separado. Glacier Deep Archive es una clase de archivado pensada para una recuperación lenta, y ElastiCache es una caché en memoria, no un sistema de archivos.

EBS es almacenamiento en bloques persistente para instancias EC2 que se replica automáticamente dentro de una zona de disponibilidad (アベイラビリティゾーン) y ofrece un rendimiento uniforme y de baja latencia. Debido a esta propiedad de una sola AZ, si se necesita disponibilidad entre AZ hace falta otro mecanismo. Replicar entre regiones (リージョン) o entregar desde ubicaciones de borde no es la función de EBS.

S3 Glacier es un grupo de clases de almacenamiento (ストレージクラス) de archivado (アーカイブ): S3 Glacier Instant Retrieval, para datos que requieren recuperación inmediata; S3 Glacier Flexible Retrieval, para datos a largo plazo a los que se accede rara vez; y S3 Glacier Deep Archive, que recupera los datos al menor costo en un plazo de horas. El diseño permite elegir una clase según el equilibrio entre la velocidad de recuperación y el costo, por lo que el tiempo de recuperación no es uniforme. No hay restricciones sobre el tipo de datos que se pueden almacenar, y no se usa conectándolo como almacenamiento en bloques.

S3 es almacenamiento de objetos (オブジェクトストレージ), EBS es almacenamiento en bloques (ブロックストレージ) que se conecta a EC2 y EFS es almacenamiento de archivos (ファイルストレージ) para cargas de trabajo de Linux. Ayuda pensar en los objetos como algo que se mete y se saca entero mediante una API, en los bloques como algo que el sistema operativo ve como un disco, y en los archivos como algo que se puede montar y compartir desde varios hosts; con este esquema es más fácil elegir con seguridad a partir de los requisitos.

EBS es un almacenamiento en bloques persistente para usar con instancias EC2 que ofrece un rendimiento uniforme y de baja latencia (低レイテンシ), por lo que es muy adecuado como disco del sistema operativo o de una base de datos. S3 es almacenamiento de objetos y no conecta un bucket como dispositivo de bloques (ブロックデバイス). Glacier es una clase de archivado pensada para una recuperación lenta, y CloudFront es una CDN para acelerar la entrega.

S3 es un almacenamiento de objetos capaz de guardar y proteger cualquier cantidad de datos, con excelente escalabilidad (スケーラビリティ), disponibilidad (可用性), seguridad y rendimiento, y AWS menciona oficialmente casos de uso como web, móvil, copias de seguridad, archivado, IoT y análisis de big data. Que el sistema operativo lo vea como un disco es una propiedad de EBS; limitarse en principio a la conexión con una sola instancia también es una propiedad de EBS; y guardar los datos en memoria es una propiedad de ElastiCache.

EFS es un sistema de archivos sencillo, escalable y elástico (エラスティック) cuya capacidad crece y se reduce automáticamente a medida que se agregan y eliminan archivos, lo que elimina la necesidad de planificar la capacidad de antemano (事前の容量設計). Fijar de antemano una capacidad decidida, o reconstruirlo para ampliarla, corresponde a la forma de pensar del almacenamiento en bloques, y el tamaño de la memoria de la instancia conectada tampoco determina la capacidad. Esta elasticidad es lo que lo hace fácil de usar como área de trabajo compartida.

S3 Glacier Deep Archive almacena al menor costo los datos a los que se accede rara vez, con una recuperación que tarda unas horas, por lo que se ajusta a esta condición. EBS y EFS están diseñados para mantener la velocidad de recuperación y tienden a ser caros como lugar para datos que permanecen inactivos mucho tiempo. ElastiCache es una caché en memoria (インメモリのキャッシュ) y, para empezar, no es un mecanismo de almacenamiento a largo plazo. Decidir de antemano cuánto tiempo de espera de recuperación es aceptable es la lógica que guía la elección de la clase de almacenamiento (ストレージクラス).

RDS es un servicio administrado que facilita configurar, operar y escalar una base de datos relacional (リレーショナルデータベース) en la nube, y automatiza tareas de administración como el aprovisionamiento de hardware, la configuración de la base de datos, la aplicación de parches (パッチ適用) y las copias de seguridad. Diseñar tablas y columnas, decidir los índices, construir la aplicación y validar que el contenido de los datos sea correcto siguen siendo tarea del cliente. Administrado (マネージド) significa que se delega la carga operativa, no que también se delegue el diseño.

Aurora forma parte de Amazon RDS, el servicio de bases de datos administrado, y usa la misma consola de administración, la misma CLI y las mismas operaciones de API para el aprovisionamiento, la aplicación de parches, las copias de seguridad, la recuperación y la detección de fallos. La diferencia está en la unidad de administración: RDS estándar administra instancias de base de datos individuales, mientras que Aurora administra un clúster (クラスター) completo de servidores de base de datos sincronizados mediante replicación (レプリケーション). Aurora es una base de datos relacional compatible con MySQL y PostgreSQL, no una base de datos de clave-valor.

DynamoDB es una base de datos NoSQL de clave-valor (キーバリュー型) y de documentos (ドキュメント型), totalmente administrada y multirregión, que ofrece un rendimiento de milisegundos de un solo dígito a cualquier escala. Un almacén de datos es Redshift, una base de datos relacional compatible con MySQL y PostgreSQL es Aurora, y leer y escribir en memoria corresponde a ElastiCache.

Redshift es un servicio de almacén de datos (データウェアハウス) totalmente administrado, a escala de petabytes y en la nube, que ofrece un rendimiento de consulta rápido desde herramientas basadas en SQL o aplicaciones de BI existentes, sea cual sea el tamaño del conjunto de datos. ElastiCache es una caché en memoria, EFS es un sistema de archivos compartido y SQS es una cola de mensajes; ninguno de ellos es una plataforma para agregar y analizar grandes volúmenes de datos.

ElastiCache es un servicio que facilita desplegar, operar y escalar una caché en memoria (インメモリキャッシュ) en la nube, y mejora el rendimiento de las aplicaciones web al obtener la información de una caché en memoria rápida en lugar de depender de una base de datos basada en disco. Acelerar las consultas analíticas es tarea de Redshift, reducir el costo del almacenamiento a largo plazo es tarea de las clases de S3 Glacier, y compartir un directorio es tarea de EFS.

Aurora es un motor de base de datos relacional totalmente administrado y compatible con MySQL y PostgreSQL, con un subsistema de almacenamiento distribuido y compartido (分散共有ストレージ) de alto rendimiento, cuyo almacenamiento se amplía automáticamente según sea necesario. No hace falta decidir la capacidad de antemano ni ampliarla manualmente. Almacenar los datos como pares clave-valor corresponde a DynamoDB, y mantener barato el almacenamiento a cambio de que la recuperación tarde corresponde a una clase de archivado de S3 Glacier.

Redshift es un servicio de almacén de datos (データウェアハウス) totalmente administrado y a escala de petabytes, muy adecuado para agregar y analizar grandes volúmenes de datos desde herramientas basadas en SQL o aplicaciones de BI. RDS es un servicio que facilita configurar, operar y escalar una base de datos relacional, muy adecuado para que un sistema de negocio lea y escriba las transacciones (取引) del día a día. Ambos se consultan con SQL, lo que puede hacer que parezcan similares, pero ninguno es NoSQL, y la diferencia no es solo de volumen de datos.

DynamoDB es una base de datos NoSQL de clave-valor (キーバリュー型) y de documentos que, según la descripción oficial, ofrece un rendimiento de milisegundos de un solo dígito a cualquier escala. Redshift es un almacén de datos muy adecuado para agregar y analizar grandes volúmenes de datos, RDS es un servicio para leer y escribir bajo el modelo relacional, y EFS es un almacenamiento para compartir archivos; ninguno de ellos apunta principalmente a este requisito.

RDS es Amazon Relational Database Service, un servicio administrado que facilita configurar, operar y escalar una base de datos relacional (リレーショナルデータベース) en la nube. Almacenar los datos como pares clave-valor corresponde a DynamoDB, la caché en memoria es ElastiCache, y agregar grandes volúmenes de datos es tarea del almacén de datos Redshift. Cabe señalar que Aurora es un motor que se ofrece como parte de RDS.

Aurora se ofrece como parte de RDS, y el aprovisionamiento, la aplicación de parches, las copias de seguridad, la recuperación y la detección de fallos (障害検知) pueden hacerse con la misma consola de administración, la misma CLI y las mismas operaciones de API. No hace falta poner en marcha una instancia de administración separada, ni que el cliente construya estos procedimientos por sí mismo. La diferencia con RDS estándar, que administra instancias de base de datos individuales, es que Aurora toma el clúster completo como unidad de administración.

SQS es un servicio punto a punto (ポイントツーポイント) que retiene los mensajes en una cola (キュー), de donde normalmente los saca un único consumidor mediante sondeo. SNS es un servicio de publicación/suscripción (パブサブ) en el que los publicadores envían mensajes a un tema (トピック) y estos se envían (push) simultáneamente a varios suscriptores. Intercambiar ambos es una confusión clásica, y tampoco es cierto que ambos entreguen de la misma manera. Ayuda recordar la dirección: una cola es un lugar al que el receptor va a buscar, y un tema es un emisor que empuja hacia fuera.

SQS tiene colas estándar (標準キュー) y colas FIFO (FIFO キュー). Las colas estándar ofrecen entrega at-least-once (al menos una vez), por lo que el mismo mensaje puede llegar más de una vez. Las colas FIFO ofrecen procesamiento exactly-once (exactamente una vez) y conservación del orden, de modo que se mantiene el orden de envío y cada mensaje se procesa exactamente una vez. Para flujos de trabajo en los que importan el orden y evitar pérdidas, la opción es una cola FIFO.

SNS envía (push) simultáneamente un mensaje enviado a un tema a varios suscriptores, y se puede especificar una cola de SQS como suscriptor. Esta forma, de un tema de SNS a varias colas de SQS, es el patrón fan-out (ファンアウトパターン, distribución en abanico) que se presenta oficialmente como el enfoque estándar. Una cola es un extremo receptor, no un origen de entrega, por lo que la dirección nunca va de la cola al tema.

Los tipos de suscriptores (サブスクライバー) de SNS se organizan en dos grupos: A2A, que son destinos de aplicación a aplicación como SQS, Lambda, HTTP(S) y Data Firehose; y A2P, que son destinos de aplicación a persona como el correo electrónico, las notificaciones push móviles y los SMS. No se limita a uno de los dos grupos, ni es un mecanismo limitado a instancias EC2 como destino. Esta amplitud es la razón por la que SNS se usa tanto para notificar a personas como para conectar aplicaciones.

Step Functions es un servicio que permite crear flujos de trabajo (ワークフロー), es decir, máquinas de estados (ステートマシン), y que hace posible construir aplicaciones distribuidas, automatizar procesos, orquestar microservicios y crear canalizaciones de datos o de aprendizaje automático. Cada paso se denomina state (estado) y cada instancia en ejecución se denomina execution (ejecución). Distribuir el tráfico es tarea de Elastic Load Balancing, almacenar objetos es tarea de S3, y almacenar en caché pares clave-valor es el ámbito de ElastiCache.

API Gateway es un servicio para crear, publicar, mantener, supervisar y proteger API REST, HTTP y WebSocket a cualquier escala, y funciona como la puerta de entrada (フロントドア) para el acceso a backends como cargas de trabajo en EC2, Lambda o cualquier aplicación web. Ejecutar el propio procesamiento es tarea del backend, aplicar reglas de protección de forma centralizada en varias cuentas es tarea de AWS Firewall Manager, y almacenar en caché en el borde es la función de CloudFront.

EventBridge es un servicio sin servidor que conecta entre sí los componentes de una aplicación mediante eventos, y se encarga de la ingesta, el filtrado, la transformación y la entrega de eventos. Un bus de eventos (イベントバス) es un enrutador (ルーター) que dirige eventos desde muchos orígenes hacia muchos destinos. Una cola describe a SQS, una máquina de estados a Step Functions, y una puerta de entrada a API Gateway.

EventBridge Scheduler es un mecanismo para administrar invocaciones periódicas (定期実行) y únicas mediante expresiones cron o expresiones rate, por lo que la invocación programada a horas fijas se gestiona aquí. SQS es una cola que retiene mensajes para que un receptor los saque, SNS es una entrega de publicación/suscripción a suscriptores, y API Gateway es un servicio para publicar y retransmitir API; ninguno de ellos apunta a una invocación basada en la hora.

SQS es un servicio de colas alojado, seguro, duradero y de alta disponibilidad, que permite integrar y desacoplar (疎結合化) sistemas y componentes de software distribuidos. El lado de recepción puede responder en cuanto coloca un mensaje en la cola, y el proceso posterior puede sacarlo y continuar a su propio ritmo, de modo que un retraso en un lado no detiene fácilmente al otro. En una configuración de llamada directa o de un solo programa, un retraso en el proceso posterior se convierte en tiempo de espera para el lado de recepción.

SNS envía (push) simultáneamente un mensaje enviado a un tema a varios suscriptores, y se puede especificar una cola de SQS como suscriptor, por lo que entregar un solo evento a tres procesos requiere el patrón fan-out (ファンアウトパターン) de un tema de SNS con varias colas de SQS. Si tres procesos comparten una sola cola, normalmente, en cuanto uno de ellos saca un elemento, los demás ya no pueden recibirlo. Hacer que el origen envíe tres veces, o que el proceso receptor lo reenvíe, implica modificar el emisor cada vez que se añade un destino, lo cual no es acoplamiento débil (疎結合).