Comprender la estructura y los servicios clave de AWS

Inicio » Internet » Comprender la estructura y los servicios clave de AWS

Si te estás peleando con la nube y te suena todo a ciencia ficción, tranquilo: Amazon Web Services (AWS) puede parecer un monstruo con cientos de servicios, pero su estructura tiene mucha lógica en cuanto la miras con calma. El objetivo de esta guía es justo ese: aterrizar conceptos, ordenar ideas y que veas cómo encaja cada pieza del puzzle.

Antes de meternos en faena, conviene tener clara una idea: comprender la estructura y servicios de AWS no va solo de memorizar nombres, sino de entender cómo se organiza su infraestructura global, qué hace cada categoría (cómputo, almacenamiento, red, seguridad, analítica, etc.) y cómo se reparten las responsabilidades entre Amazon y tú dentro del modelo de seguridad compartida.

Del centro de datos tradicional a la nube de AWS

Durante años, las empresas montaban sus propios CPD (centros de datos tradicionales): rack tras rack de servidores, almacenamiento, switches, SAI, refrigeración y un equipo entero dedicado solo a “que no se caiga nada”. Cada nuevo entorno (desarrollo, pruebas, preproducción…) implicaba comprar hardware, cablear, instalar sistemas operativos y cruzar los dedos para que todo llegara a tiempo.

Este modelo hacía que muchas cargas de trabajo fueran demasiado caras o lentas de desplegar, y prácticamente mataba la experimentación: si querías probar una idea nueva necesitabas inversión, tiempo y justificarlo todo con antelación.

Con la expansión de Internet, el problema se multiplicó: el consumo de cómputo, almacenamiento y red creció tanto que mantener grandes centros de datos propios dejó de ser viable para muchas organizaciones. Ahí es donde aparece la computación en la nube, y donde Amazon Web Services se coloca en primera fila.

En AWS, si un equipo de desarrollo quiere un entorno de QA igualito al de producción, puede clonar esa infraestructura completa en minutos, automatizada y sin tocar ni un cable. Lo que antes suponía semanas de trabajo físico, ahora se gestiona por consola, API o CLI.

El gran cambio es que tú te centras en lo que aporta valor (el código, los datos, la lógica de negocio), mientras AWS se encarga del “trabajo pesado indiferenciado”: servidores físicos, red, energía, refrigeración y gran parte de la automatización de la infraestructura.

Infraestructura global de AWS: regiones, AZ y edge locations

Lo primero para comprender la estructura de AWS es su distribución física por el mundo. Todo se construye a partir de tres conceptos clave: regiones, zonas de disponibilidad y ubicaciones de borde.

Regiones y zonas de disponibilidad

Una región de AWS es una localización geográfica que agrupa varios centros de datos independientes. Cada región está formada por al menos dos “Availability Zones” (AZ), que son conjuntos de centros de datos aislados entre sí a nivel de energía, red y refrigeración, pero unidos por enlaces de baja latencia.

Esto permite que puedas desplegar tu aplicación en varias AZ dentro de la misma región para ganar alta disponibilidad: si una AZ falla, las otras pueden seguir atendiendo tráfico. Para el usuario final todo sigue funcionando, aunque por detrás haya caído un centro de datos completo.

A nivel de continentes, AWS cuenta con regiones repartidas por todo el mundo. Algunos ejemplos representativos son US East (N. Virginia, Ohio), US West (Oregon), EU (Irlanda, Frankfurt), South America (São Paulo) o varias regiones en Asia-Pacífico como Singapur, Tokio, Sídney, Seúl o Mumbai, además de regiones específicas como AWS GovCloud o las regiones de China.

Edge locations y entrega de contenido

Además de regiones y AZ, AWS mantiene edge locations (puntos de presencia) que utiliza principalmente su red de distribución de contenido, Amazon CloudFront. Hay muchas más ubicaciones de borde que zonas de disponibilidad, y se sitúan cerca de grandes núcleos de usuarios finales, por ejemplo en ciudades como Ashburn o Atlanta.

Cuando sirves contenido estático o multimedia con CloudFront, ese contenido se cachea en estas edge locations para reducir latencia y mejorar la experiencia de usuario. Para quien navega, la web “vuela” porque los datos viajan desde un punto de red cercano.

Estructura lógica de los servicios de AWS

Por encima de esa infraestructura física, AWS organiza sus servicios en grandes categorías: computación, almacenamiento, bases de datos, redes, seguridad, analítica, migración, herramientas de gestión, IA, IoT, mensajería, etc.. Piensa en ellas como en “capas” o bloques que se combinan entre sí para construir arquitecturas.

Una de las grandes ventajas de AWS frente a otros proveedores es que no solo tiene muchos servicios, sino que además profundiza mucho en cada categoría: por ejemplo, ofrece distintos tipos de bases de datos, cada una optimizada para casos de uso concretos, en lugar de forzarte a usar una sola para todo.

Servicios de red en AWS

En la base de casi cualquier despliegue serio en AWS vas a encontrar la red. Los servicios de red definen cómo se conectan tus recursos entre sí y con el exterior, y qué caminos sigue el tráfico.

• Amazon VPC (Virtual Private Cloud): red virtual aislada dentro de AWS donde defines rangos CIDR, subredes, tablas de rutas, gateways y seguridad de red. Es como tu propio “CPD lógico” en la nube.
• Amazon Route 53: servicio DNS escalable que resuelve nombres de dominio y permite enrutar tráfico a aplicaciones en AWS o fuera de ella.
• Amazon CloudFront: red de distribución de contenido (CDN) que usa las edge locations para servir contenido con baja latencia.
• AWS Direct Connect: enlace de red dedicado entre tus instalaciones on-premise y AWS, evitando Internet público y mejorando ancho de banda y estabilidad.

Servicios de computación en AWS

La parte de cómputo es, probablemente, la más conocida. Aquí es donde ejecutas tus aplicaciones, ya sea en máquinas virtuales, contenedores o funciones serverless.

• Amazon EC2 (Elastic Compute Cloud): instancias (máquinas virtuales) en la nube que puedes dimensionar, parar, arrancar o escalar según necesidad. Es la opción clásica para migrar servidores.
• Amazon ECS (Elastic Container Service) y Amazon EKS: servicios de orquestación de contenedores; ECS está orientado a Docker gestionado por AWS y EKS proporciona Kubernetes administrado.
• Amazon Fargate: motor serverless para contenedores que elimina la gestión de servidores o clústeres; tú defines contenedores y recursos, y AWS se encarga del resto.
• AWS Lambda: ejecución de funciones sin servidor; subes el código y solo pagas por el tiempo de ejecución. Ideal para arquitecturas orientadas a eventos.
• Elastic Beanstalk: plataforma PaaS que automatiza despliegue y escalado de aplicaciones web (Java, .NET, PHP, Node.js, Python, Ruby, Go, etc.) sobre infraestructura AWS.
• Lightsail: VPS simplificados con plantillas preconfiguradas para quien quiere desplegar aplicaciones sin complicarse con todo el ecosistema AWS.

Un buen ejemplo de la elasticidad de AWS es el caso de investigadores de la Universidad de Clemson, que levantaron en menos de 24 horas un clúster de más de 1.100.000 vCPU usando instancias spot de EC2 en una sola región para experimentos de machine learning. Algo así, on-premise, simplemente no es realista.

Servicios de almacenamiento en AWS

En la nube, almacenar datos no es simplemente “tener disco”: dependiendo de si necesitas acceso en milisegundos, archivado barato o un sistema de ficheros compartido, usarás un servicio u otro.

• Amazon S3 (Simple Storage Service): almacenamiento de objetos extremadamente duradero (11 nueves), escalable y seguro. Ideal para copias de seguridad, estáticos web, data lakes, contenidos multimedia, IoT, etc.
• Amazon S3 Glacier: clase de almacenamiento de muy bajo coste pensada para archivado y backups a largo plazo, con distintos tiempos de recuperación.
• Amazon EBS (Elastic Block Store): volúmenes de bloques de alto rendimiento asociados a instancias EC2. Perfecto para bases de datos, sistemas de archivos y aplicaciones con I/O intenso.
• Amazon EFS (Elastic File System): sistema de ficheros NFS totalmente gestionado que escala automáticamente y puede montarse desde instancias EC2 y entornos on-premise.
• AWS Storage Gateway: puente entre tu centro de datos y S3 para exponer almacenamiento cloud como si fuera local (volúmenes, ficheros o backups).

Bases de datos en AWS

En datos, AWS juega en otra liga porque no se limita a bases relacionales: ofrece motores para SQL, NoSQL, data warehouse, caché y análisis a gran escala.

• Amazon RDS: servicio gestionado de bases de datos relacionales (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server). Automatiza parches, backups y escalado.
• Amazon Aurora: base de datos relacional compatible con MySQL y PostgreSQL, diseñada por AWS, muy optimizada y con mayor rendimiento que las instalaciones estándar.
• Amazon DynamoDB: base de datos NoSQL de documentos y clave-valor, totalmente gestionada, con latencias de un solo dígito en cualquier escala.
• Amazon Redshift: data warehouse para consultas analíticas sobre teras o petabytes de datos, con integración directa con S3.
• ElastiCache: servicio gestionado de caché en memoria (Redis/Memcached) para reducir latencias y descargar bases de datos.

Servicios de análisis y Big Data

Cuando la cantidad de información crece, necesitas herramientas para procesos ETL para procesarla, consultarla y visualizarla sin reinventar la rueda. Ahí entran los servicios de analítica de AWS.

• Amazon Athena: permite lanzar consultas SQL directamente sobre datos almacenados en S3 sin necesidad de provisionar servidores.
• Amazon EMR (Elastic MapReduce): plataforma administrada para big data basada en frameworks como Hadoop, Spark, Hive o HBase.
• Amazon Kinesis: familia de servicios para ingesta y análisis de datos en streaming, muy útil en casos financieros, logs en tiempo real o IoT.
• AWS Data Pipeline: orquestación de movimientos de datos entre servicios (por ejemplo de DynamoDB a S3) siguiendo workflows definidos.
• Amazon OpenSearch Service (antes Elasticsearch) y CloudSearch: motores de búsqueda gestionados para aplicaciones que necesitan indexación y consulta avanzada.
• Amazon QuickSight: herramienta de BI para crear dashboards e informes interactivos a partir de datos en AWS.

Migración de datos y cargas de trabajo

Para muchas organizaciones, el primer reto no es qué construir, sino cómo llevar lo que ya tienen a AWS sin morir en el intento. Para eso existen servicios específicos de migración.

• AWS Snowball: dispositivo físico robusto que se envía al cliente para copiar grandes volúmenes de datos localmente y luego cargarlos en AWS desde los centros de datos de Amazon.
• AWS Database Migration Service (DMS): migra bases de datos hacia AWS o entre regiones/motores con mínimo tiempo de inactividad.
• AWS Server Migration Service (SMS): automatiza la migración de máquinas virtuales on-premise a instancias EC2.

Seguridad, identidad y cumplimiento en AWS

La seguridad es uno de los pilares de la plataforma. AWS ofrece herramientas para controlar quién accede a qué, cómo se cifran los datos y cómo se audita todo lo que ocurre.

• AWS Identity and Access Management (IAM): sistema centralizado para crear usuarios, grupos, roles y políticas de permisos sobre recursos de AWS.
• AWS Organizations: gestión de múltiples cuentas AWS bajo una misma organización, con políticas a nivel global para restringir servicios o acciones.
• AWS Key Management Service (KMS): gestión de claves de cifrado para datos en reposo y en tránsito, integradas con la mayoría de servicios.
• AWS Artifact: acceso bajo demanda a informes y documentación de seguridad y cumplimiento (ISO, SOC, PCI, etc.).
• AWS Shield y AWS WAF: protección contra ataques DDoS y firewall de aplicaciones web configurable por reglas.
• AWS Directory Service: integración con Active Directory para federar identidades corporativas.
• Inspector y otras herramientas de auditoría: análisis automatizado de vulnerabilidades y configuración de instancias EC2.

Modelo de responsabilidad compartida

Un punto que mucha gente pasa por alto es que la seguridad en AWS se basa en un modelo de responsabilidad compartida. No todo lo hace Amazon, ni todo recae en el cliente; cada uno tiene su parte.

AWS se encarga de la seguridad “de la nube”: centros de datos físicos (controles de acceso, cámaras, destrucción de discos), hardware, red, hipervisores, sistemas subyacentes y la plataforma de los servicios gestionados.

Tú eres responsable de la seguridad “en la nube”: sistema operativo de tus instancias EC2 (parches, antivirus), configuración de aplicaciones, definición de permisos IAM, reglas de grupos de seguridad, cifrado de datos, gestión de usuarios y credenciales, y, en general, de todo lo que subes y cómo lo configuras.

Además, decides en qué región se almacenan tus datos, quién puede acceder a ellos, si están cifrados y cómo. AWS te da las herramientas, pero el diseño de esa política de uso es cosa tuya.

AWS IAM en detalle: usuarios, grupos, roles y políticas

Para no convertir tu cuenta en el Lejano Oeste, IAM es la pieza clave que te permite controlar exactamente quién puede hacer qué dentro de AWS.

• Usuarios: identidades individuales (personas o aplicaciones) con credenciales propias. No se comparten y se limitan a una sola cuenta AWS.
• Grupos: colecciones de usuarios que comparten el mismo conjunto de permisos. Un usuario puede pertenecer a varios grupos, y un grupo puede contener muchos usuarios.
• Roles: identidades con permisos definidos que se asumen temporalmente, pensadas para delegar acceso a servicios, aplicaciones o incluso otras cuentas sin compartir credenciales a largo plazo.
• Políticas: documentos JSON que describen qué acciones están permitidas o denegadas sobre qué recursos y bajo qué condiciones.

Las políticas pueden ser basadas en identidad (adjuntas a usuarios, grupos o roles) o basadas en recursos (por ejemplo, una bucket policy en S3). Y la lógica de decisión es clara: si hay una denegación explícita, manda; si no, se mira si hay una concesión explícita; si no hay ninguna de las dos, la respuesta es denegación implícita.

En autenticación puedes optar por acceso programático (claves de acceso), acceso a consola (usuario/contraseña con MFA) o ambos. A partir de ahí, todo se rige por las políticas concedidas.

Buenas prácticas de seguridad en IAM

Para no llevarte sustos, merece la pena adoptar desde el principio unas cuantas prácticas recomendadas muy asumidas en el mundo AWS:

1. Usar el usuario raíz solo para lo imprescindible y proteger sus credenciales con MFA.
2. Crear usuarios individuales de IAM; nada de cuentas compartidas.
3. Asignar permisos a través de grupos, no usuario a usuario.
4. Aplicar el principio de mínimo privilegio: dar solo los permisos estrictamente necesarios.
5. Aprovechar políticas administradas de AWS como punto de partida y luego afinar.
6. Revisar y validar las políticas que crees tú mismo.
7. Rotar credenciales periódicamente y eliminar las que no se usan.
8. Habilitar contraseñas fuertes y MFA para todos los usuarios de consola.
9. Usar roles para aplicaciones en EC2 y para delegar acceso entre cuentas.
10. Monitorizar la actividad de la cuenta con CloudTrail y otras herramientas.

Herramientas de monitorización, gobierno y costes

A medida que tu cuenta crece, necesitas visibilidad sobre qué recursos existen, qué están haciendo y cuánto te están costando. AWS ofrece varias piezas para esto.

• Amazon CloudWatch: monitoriza recursos y aplicaciones (CPU, memoria, disco, logs) y permite crear alarmas y dashboards.
• AWS CloudTrail: registra cada llamada a la API de AWS (quién hizo qué y cuándo), fundamental para auditoría y seguridad.
• AWS Config: mantiene un inventario de recursos y un historial de cambios de configuración para comprobar cumplimiento y rastrear desviaciones.
• OpsWorks, CloudFormation y Step Functions: ayudan a describir y orquestar infraestructura y flujos de trabajo como código.
• AWS Service Catalog: catálogo de productos y plantillas aprobadas para que los equipos desplieguen recursos cumpliendo estándares corporativos.
• Trusted Advisor: recomienda optimizaciones en seguridad, coste, rendimiento y tolerancia a fallos.
• AWS Budgets, Cost Explorer y Cost & Usage Report: herramientas específicas para controlar y analizar el gasto en detalle.

Redes en profundidad: VPC, subredes, tablas de rutas y seguridad

Volviendo a la red, dentro de una VPC se trabaja con rangos de IP definidos con CIDR (por ejemplo 192.0.2.0/24). AWS reserva siempre las primeras cuatro direcciones IP y la última de cada subred para su uso interno, así que tus IP utilizables son menos que las teóricas.

La VPC se divide en subredes, cada una ubicada en una única AZ. Si una subred tiene una ruta hacia un Internet Gateway, se considera pública; si no, es privada. Las subredes privadas pueden salir a Internet usando un NAT Gateway o NAT Instance definido en la tabla de rutas.

Las tablas de enrutamiento contienen las reglas (rutas) que determinan por dónde sale el tráfico. Cada subred debe estar asociada a una tabla, que siempre incluye una ruta local para la propia VPC; el resto las defines tú.

La seguridad de red se controla principalmente con grupos de seguridad (firewall virtual a nivel de instancia) y ACL de red (listas de control de acceso a nivel de subred). Los grupos de seguridad permiten o deniegan tráfico entrante y saliente en función de puertos, protocolos y orígenes/destinos.

Para facilitar el arranque, el asistente VPC Wizard ofrece varios patrones predefinidos: una única subred pública, combinación de públicas y privadas, integración con VPN on-premise, etc. A partir de ahí siempre puedes ajustar a mano.

Direcciones IP elásticas

Cuando lanzas una instancia EC2 en una subred pública, AWS puede asignarle una IP pública aleatoria que cambiará al detener y arrancar la máquina. Si quieres una IP fija para asociarla a un dominio o moverte entre instancias, necesitas una Elastic IP.

Una Elastic IP es una dirección IP pública estática que puedes asociar y desasociar de instancias a voluntad. Es muy útil para planes de contingencia: si una instancia falla, reasignas la IP a otra y el tráfico sigue llegando.

Eso sí, AWS cobra una pequeña cantidad por cada Elastic IP no asociada a un recurso en ejecución, para evitar que la gente acapare direcciones. Por defecto, cada cuenta tiene un límite de cinco Elastic IP por región (ampliable bajo solicitud).

AWS CLI y CloudShell

Además de la consola web, AWS proporciona la Command Line Interface (AWS CLI) para gestionar recursos desde terminal. Con ella puedes describir instancias EC2, lanzar servicios, consultar identidad, automatizar scripts, etc.

Tras instalar AWS CLI v2 y configurar credenciales (ya sea mediante fichero ~/.aws/credentials o variables de entorno), puedes comprobar tu identidad con aws sts get-caller-identity y listar recursos, por ejemplo con aws ec2 describe-instances.

Si no quieres preocuparte de instalar nada localmente, AWS CloudShell te da un shell directamente en la consola web, ya autenticado con tu usuario, y con las herramientas básicas (AWS CLI, SDKs) listas para usar.

Todo este ecosistema —infraestructura global, servicios organizados por categorías, seguridad bien delimitada por el modelo de responsabilidad compartida y una batería de herramientas de automatización, monitorización y control de costes— hace que AWS sea hoy una plataforma capaz de cubrir desde el hosting de una web sencilla hasta arquitecturas distribuidas a escala planetaria, siempre que dediques un poco de tiempo a comprender cómo se estructura y cómo encaja cada servicio en tu diseño.