Cloud

AWS Solutions Architect Associate (SAA) 2018 – III

Posted on by Ruben Ortiz

Seguimos con los posts dedicados a la certificación AWS Certified Solutions Architect Associate (SAA-C03), repasando algunos de los servicios fundamentales de AWS relacionados con computación, almacenamiento, balanceo de carga y escalado automático. SAA-C03 continúa siendo actualmente la versión vigente del examen Associate. Vamos a ver los apuntes para el AWS Solutions Architect Associate SAA en el que tocaremos temas como las EC2.

En este artículo veremos:

EC2

Amazon EC2 permite desplegar servidores virtuales dentro de AWS utilizando diferentes tipos de instancia, arquitecturas y modelos de compra.

Opciones de compra de EC2

Actualmente AWS ofrece varias opciones principales:

  • On-Demand Instances
  • Savings Plans
  • Reserved Instances
  • Spot Instances
  • Dedicated Hosts
  • Dedicated Instances
  • Capacity Reservations

AWS recomienda actualmente Savings Plans frente a Reserved Instances para la mayoría de escenarios donde buscamos reducir costes mediante un compromiso de uno o tres años, ya que ofrecen mayor flexibilidad.

On-Demand

Las instancias On-Demand permiten consumir capacidad EC2 sin compromisos a largo plazo.

Son apropiadas para:

  • cargas de trabajo impredecibles;
  • aplicaciones en desarrollo;
  • cargas de corta duración;
  • sistemas que no pueden tolerar interrupciones;
  • escenarios donde no conocemos todavía el consumo futuro.

Pagamos únicamente por la capacidad consumida.

Savings Plans y Reserved Instances

Los Savings Plans permiten obtener descuentos comprometiéndonos a un determinado consumo de computación, expresado en dólares por hora, durante uno o tres años.

Las Reserved Instances (RI) siguen existiendo y también permiten reducir costes respecto a On-Demand, pero están asociadas a una configuración más concreta.

Una diferencia importante es que una Reserved Instance no es simplemente una máquina EC2 reservada: principalmente proporciona un beneficio de facturación. Si necesitamos garantizar capacidad física en una Availability Zone debemos estudiar Capacity Reservations.

Las antiguas Scheduled Reserved Instances, que permitían reservar capacidad según un horario periódico, ya no se pueden comprar. Para reservar capacidad AWS recomienda utilizar Capacity Reservations y, para obtener descuentos, Savings Plans.

Spot Instances

Las Spot Instances utilizan capacidad EC2 disponible y permiten reducir significativamente el coste respecto a On-Demand.

La contrapartida es que AWS puede interrumpir una Spot Instance cuando necesita recuperar esa capacidad.

Las principales causas de interrupción son:

  • falta de capacidad disponible;
  • mantenimiento o retirada de hardware;
  • restricciones de nuestra solicitud;
  • que el precio Spot supere un precio máximo que hayamos configurado.

Aunque todavía es posible establecer un precio máximo, AWS recomienda normalmente no configurarlo, ya que hacerlo puede incrementar la frecuencia de interrupciones.

Spot resulta especialmente interesante para:

  • procesamiento batch;
  • CI/CD;
  • renderizado;
  • análisis de datos;
  • workloads stateless;
  • procesamiento distribuido;
  • aplicaciones capaces de recuperarse de una interrupción.

Las antiguas Spot Blocks, que permitían solicitar Spot Instances durante un período fijo sin interrupciones, dejaron de estar disponibles para nuevos clientes en 2021 y su soporte terminó en 2022.

EC2 Fleet y Spot Fleet

Históricamente Spot Fleet permitía definir varios pools de instancias y mantener una capacidad objetivo.

Actualmente AWS considera Spot Fleet una API legacy sin nuevas inversiones y recomienda utilizar:

  1. EC2 Auto Scaling, como primera opción para administrar automáticamente el ciclo de vida de las instancias.
  2. EC2 Fleet, cuando queremos administrar nosotros mismos una flota.
  3. Spot Fleet únicamente para casos heredados donde siga siendo necesario.

Para workloads Spot, AWS recomienda actualmente la estrategia:

price-capacity-optimized

Esta estrategia selecciona pools teniendo en cuenta tanto la disponibilidad de capacidad como el precio, reduciendo la probabilidad de interrupciones.

La antigua estrategia lowest-price continúa existiendo, pero AWS ya no la recomienda como estrategia general.

Dedicated Hosts

Un Dedicated Host proporciona un servidor físico EC2 dedicado exclusivamente a nuestra cuenta.

Puede ser útil cuando:

  • existen requisitos regulatorios;
  • necesitamos aislamiento físico;
  • utilizamos licencias vinculadas a sockets, cores o máquinas físicas;
  • determinadas aplicaciones requieren visibilidad o control sobre el host físico.

No debemos confundir Dedicated Hosts con Bare Metal.

Tipos de instancia EC2

La cantidad de familias EC2 ha crecido enormemente, por lo que ya no tiene demasiado sentido memorizar una lista de letras como ocurría en los primeros exámenes de AWS.

Las categorías principales son:

  • General Purpose: equilibrio entre CPU, memoria y red. Ejemplos: M y T.
  • Compute Optimized: workloads intensivos en CPU. Familia C.
  • Memory Optimized: grandes cantidades de memoria. Familias R, X o U.
  • Storage Optimized: almacenamiento local de alto rendimiento. Familias I, D y H.
  • Accelerated Computing: GPU y aceleradores especializados. Familias G, P, Inf, Trn o F.
  • High Performance Computing: workloads HPC especializados.

AWS mantiene además generaciones anteriores para compatibilidad, pero recomienda utilizar generaciones actuales cuando sea posible.

Bare Metal Instances

Las instancias Bare Metal proporcionan acceso directo al procesador y memoria del servidor físico subyacente sin utilizar la capa de virtualización tradicional.

Son interesantes para:

  • software con restricciones de licencia;
  • determinados hipervisores;
  • workloads que necesitan acceso directo al hardware;
  • herramientas avanzadas de análisis de rendimiento;
  • determinadas cargas de alto rendimiento.

Muchas familias EC2 disponen actualmente de variantes Bare Metal.

EC2 con ARM y AWS Graviton

AWS dispone de numerosas familias EC2 basadas en procesadores AWS Graviton, arquitectura ARM.

Actualmente existen varias generaciones de Graviton y muchas familias EC2 disponen de variantes ARM, normalmente identificadas mediante una g, por ejemplo:

m8g

c8g

r8g

Estas instancias pueden ofrecer una excelente relación precio/rendimiento, pero las aplicaciones y sus dependencias deben soportar ARM64.

EC2 Status Checks

EC2 ejecuta automáticamente comprobaciones para detectar problemas que puedan impedir que una instancia funcione correctamente.

Actualmente existen cuatro tipos:

  • System Status Checks
  • Instance Status Checks
  • Attached EBS Status Checks
  • Application Status Checks

Las tres primeras son administradas automáticamente por EC2. Las Application Status Checks son opcionales y permiten incorporar la salud de nuestra propia aplicación.

System Status Checks

Detectan problemas relacionados con la infraestructura AWS subyacente:

  • pérdida de conectividad;
  • problemas de alimentación;
  • problemas en el host físico;
  • fallos de hardware;
  • problemas de red.

Si una instancia respaldada por EBS presenta este tipo de fallo, detenerla y volverla a iniciar puede provocar que sea trasladada a otro host físico.

Instance Status Checks

Detectan problemas relacionados con el sistema operativo o configuración de nuestra instancia.

Por ejemplo:

  • configuración incorrecta de red;
  • errores durante el arranque;
  • memoria agotada;
  • sistema de archivos corrupto;
  • kernel incompatible.

Generalmente estos problemas requieren intervención por nuestra parte.

Attached EBS Status Checks

AWS también comprueba si los volúmenes EBS conectados pueden recibir y completar operaciones de I/O.

Esto permite detectar problemas de almacenamiento independientemente del estado general de la instancia.

EC2 Hibernate

La hibernación permite guardar el contenido de la RAM en el volumen EBS root antes de detener una instancia.

Cuando la instancia vuelve a arrancar:

  • se restaura el volumen root;
  • se carga nuevamente el contenido de RAM;
  • se reanudan los procesos;
  • se vuelven a asociar los volúmenes;
  • se conserva el mismo Instance ID.

Es especialmente útil para aplicaciones con tiempos de inicialización largos.

Actualmente está soportada en muchas más familias de instancia que cuando apareció esta funcionalidad.

Entre los requisitos actuales encontramos:

  • root volume en EBS;
  • root volume cifrado;
  • AMI compatible;
  • tipo de instancia compatible;
  • capacidad suficiente en el volumen root para almacenar la RAM.

En Linux la instancia debe tener menos de 150 GiB de RAM y en Windows actualmente el límite es de 16 GiB.

La antigua lista limitada a C3, C4, M3, M4, etc. ya no es válida.

Recuperación automática de EC2

Podemos utilizar CloudWatch para monitorizar:

StatusCheckFailed_System

y configurar una acción automática de recuperación.

Cuando se ejecuta la recuperación, EC2 traslada la instancia mediante un reboot a infraestructura funcional, manteniendo elementos como:

  • Instance ID;
  • IP privada;
  • Elastic IP;
  • metadata de la instancia.

El contenido que únicamente estuviera en RAM se pierde durante la recuperación.

AMI

Una Amazon Machine Image (AMI) contiene la información necesaria para lanzar una instancia EC2.

Una AMI es un recurso regional.

Si queremos utilizar una AMI en otra región debemos copiarla.

AWS permite copiar:

  • AMIs basadas en EBS;
  • AMIs cifradas;
  • snapshots asociados;
  • imágenes entre regiones.

Esto es especialmente útil en estrategias de Disaster Recovery.

EBS

Amazon Elastic Block Store proporciona almacenamiento de bloques persistente para EC2.

Los volúmenes EBS:

  • existen independientemente de la instancia EC2;
  • permanecen en una Availability Zone;
  • pueden redimensionarse;
  • pueden cambiar de tipo;
  • soportan snapshots;
  • pueden cifrarse.

Un volumen EBS normal suele asociarse a una instancia, pero actualmente existe EBS Multi-Attach para volúmenes io1e io2, que permite conectar un mismo volumen a varias instancias compatibles dentro de la misma Availability Zone.

⚠️ Actualización Por tanto, la antigua afirmación de que un volumen EBS nunca puede conectarse a varias instancias ya no es correcta.

Instance Store frente a EBS

Instance Store proporciona almacenamiento físicamente asociado al host EC2.

Es almacenamiento efímero:

  • no sobrevive a determinadas operaciones sobre la instancia;
  • está asociado al ciclo de vida del host;
  • no dispone de snapshots EBS;
  • es adecuado para caches, buffers y datos temporales.

EBS, por el contrario, proporciona almacenamiento persistente independiente de la instancia.

Snapshots EBS

Los snapshots son copias point-in-time de volúmenes EBS.

AWS almacena los datos del snapshot de forma redundante utilizando Amazon S3, aunque nosotros no administramos directamente ningún bucket S3 asociado a estos snapshots.

Características importantes:

  • el primer snapshot contiene todos los bloques escritos;
  • los snapshots posteriores son incrementales;
  • los snapshots de volúmenes cifrados también están cifrados;
  • podemos crear nuevos volúmenes a partir de un snapshot;
  • los snapshots pueden copiarse entre regiones.

Para obtener máxima consistencia AWS recomienda pausar las escrituras antes de realizar el snapshot. En un volumen root puede ser recomendable detener la instancia.

Snapshots de varios volúmenes

Actualmente EBS soporta multi-volume snapshots.

Permiten crear snapshots coordinados y crash-consistent de múltiples volúmenes EBS conectados a una misma instancia.

Esto mejora considerablemente el proceso respecto a la antigua práctica de crear individualmente los snapshots de cada volumen de un RAID.

Para conseguir consistencia a nivel de aplicación —por ejemplo en determinadas bases de datos— puede seguir siendo necesario hacer flush o quiesce de la aplicación antes de iniciar el backup.

Amazon Data Lifecycle Manager

Amazon Data Lifecycle Manager (DLM) permite automatizar el ciclo de vida de:

  • snapshots EBS;
  • AMIs respaldadas por EBS.

Podemos definir políticas para:

  • creación periódica;
  • retención;
  • eliminación;
  • copia entre regiones;
  • etiquetado;
  • compartición con otras cuentas.

Para políticas de backup más amplias y centralizadas también existe AWS Backup.

DeleteOnTermination

Cuando una instancia EC2 se elimina, el atributo:

DeleteOnTermination

determina si un volumen EBS debe eliminarse junto con ella.

Por defecto, normalmente:

  • el volumen root tiene DeleteOnTermination = true;
  • los volúmenes adicionales suelen tener DeleteOnTermination = false.

Conviene comprobarlo expresamente, especialmente en entornos productivos.

Tipos de volúmenes EBS

La oferta actual es bastante diferente a la existente cuando se escribió originalmente este artículo.

gp3 — General Purpose SSD

Es la generación actual de almacenamiento SSD de propósito general.

Permite configurar de forma independiente:

  • tamaño;
  • IOPS;
  • throughput.

Actualmente soporta hasta 64 TiB, 80.000 IOPS y hasta 2.000 MiB/s, dependiendo de la configuración y de la instancia EC2.

Para nuevos diseños suele ser la opción general más interesante.

gp2 — General Purpose SSD

Continúa disponible.

Su rendimiento está relacionado con el tamaño del volumen y utiliza el conocido modelo de:

3 IOPS por GiB

con mecanismos de burst para determinados tamaños.

Sin embargo, gp3 permite desacoplar capacidad y rendimiento, por lo que gp2 ya no debería considerarse automáticamente la opción SSD por defecto al diseñar nuevas arquitecturas.

io2 — Provisioned IOPS SSD

Pensado para workloads que requieren:

  • IOPS elevadas;
  • baja latencia;
  • rendimiento consistente;
  • bases de datos I/O intensive.

io2 Block Express puede proporcionar hasta 256.000 IOPS y 4.000 MiB/s en configuraciones compatibles.

io1

Continúa soportado, aunque io2 representa la generación más moderna de Provisioned IOPS.

Tanto io1 como io2 soportan EBS Multi-Attach.

st1 — Throughput Optimized HDD

Almacenamiento HDD optimizado para throughput secuencial.

Adecuado para:

  • big data;
  • data warehouses;
  • procesamiento de logs;
  • grandes volúmenes secuenciales.

Actualmente admite volúmenes desde 125 GiB hasta 16 TiB.

No puede utilizarse como boot volume.

sc1 — Cold HDD

Pensado para grandes cantidades de datos accedidos con poca frecuencia.

Es la alternativa HDD de menor coste.

También admite actualmente volúmenes desde 125 GiB hasta 16 TiB y no puede utilizarse como boot volume.

Magnetic (standard)

Los antiguos volúmenes Magnetic todavía aparecen como previous generation.

AWS recomienda utilizar tipos de generación actual para nuevas cargas de trabajo.

Security Groups

Los Security Groups actúan como firewall virtual asociado a recursos dentro de una VPC.

Características importantes:

  • únicamente contienen reglas allow;
  • son stateful;
  • las respuestas al tráfico permitido se permiten automáticamente;
  • podemos definir reglas inbound y outbound;
  • los cambios se aplican automáticamente a los recursos asociados.

«Un Security Group en AWS es stateful, lo que significa que mantiene el estado de las conexiones permitidas: si una regla autoriza tráfico de entrada hacia un recurso, el tráfico de respuesta se permite automáticamente, sin necesidad de definir una regla específica en sentido contrario. Esto simplifica la configuración respecto a mecanismos stateless, como las Network ACLs, que evalúan cada paquete de forma independiente»

En un Security Group nuevo:

  • el tráfico inbound está bloqueado salvo que añadamos reglas;
  • normalmente existe una regla outbound que permite todo el tráfico.

Si necesitamos reglas explícitas de tipo deny, debemos estudiar mecanismos como Network ACL u otros controles de red.

Elastic Load Balancing

Actualmente AWS dispone principalmente de tres generaciones modernas de balanceadores:

  • Application Load Balancer (ALB)
  • Network Load Balancer (NLB)
  • Gateway Load Balancer (GWLB)

También sigue existiendo Classic Load Balancer, pero AWS lo considera de generación anterior y recomienda migrar a ALB o NLB.

Classic Load Balancer

Classic Load Balancer fue la primera generación del servicio ELB.

AWS continúa proporcionando soporte, pero ya no debería ser la primera opción para nuevas arquitecturas.

Las antiguas referencias a EC2-Classic también deben considerarse históricas.

Si tenemos un CLB existente, AWS proporciona mecanismos para migrarlo a:

  • Application Load Balancer;
  • Network Load Balancer.

Application Load Balancer

ALB trabaja principalmente en Layer 7.

Es adecuado para tráfico HTTP/HTTPS y permite routing avanzado.

Entre sus funcionalidades:

  • routing por hostname;
  • routing por path;
  • routing mediante headers;
  • múltiples target groups;
  • WebSockets;
  • HTTP/2;
  • gRPC;
  • TLS termination;
  • sticky sessions;
  • redirects;
  • targets EC2;
  • targets IP;
  • containers;
  • Lambda.

Cross-zone load balancing está activado por defecto a nivel de ALB.

Network Load Balancer

NLB trabaja principalmente en Layer 4 y está diseñado para cargas que requieren alto rendimiento y conexiones de red de baja latencia.

Características:

  • TCP;
  • UDP;
  • TLS;
  • gran número de conexiones simultáneas;
  • conexiones de larga duración;
  • preservación de IP del cliente en configuraciones compatibles;
  • IP estática por Availability Zone;
  • TLS termination;
  • targets EC2;
  • targets IP;
  • otros ALB como targets en determinados escenarios.

Cross-zone load balancing está desactivado por defecto, aunque puede activarse.

⚠️ Actualización – Security Groups en NLB

Una diferencia importante respecto al artículo original es que desde 2023 los Network Load Balancers soportan Security Groups. Podemos utilizar un Security Group en el propio NLB para controlar qué tráfico puede alcanzar el balanceador. Además, el Security Group de los targets puede referenciar el Security Group del NLB.

Gateway Load Balancer

Gateway Load Balancer está especializado en desplegar y escalar appliances virtuales de red.

Por ejemplo:

  • firewalls;
  • IDS/IPS;
  • sistemas de inspección profunda de paquetes;
  • appliances de seguridad de terceros.

Permite insertar estos appliances de forma transparente dentro de los flujos de red de una VPC.

Target Group Health Checks

Los balanceadores utilizan health checks para determinar si un target puede recibir tráfico.

En los target groups modernos el intervalo de health checks puede configurarse generalmente entre:

5 – 300 segundos

y el valor por defecto suele ser 30 segundos para targets EC2/IP, aunque los valores concretos dependen del tipo de balanceador, protocolo y target.

Podemos configurar parámetros como:

  • protocolo;
  • puerto;
  • path;
  • intervalo;
  • timeout;
  • healthy threshold;
  • unhealthy threshold;
  • códigos HTTP considerados válidos.

EC2 Instance Metadata

La instancia puede consultar información sobre sí misma mediante el Instance Metadata Service.

El endpoint IPv4 sigue siendo:

169.254.169.254

Pero actualmente no deberíamos utilizar directamente el antiguo ejemplo de IMDSv1:

curl http://169.254.169.254/latest/meta-data/

como recomendación de seguridad.

AWS permite exigir IMDSv2, que utiliza tokens de sesión, y podemos incluso forzarlo a nivel de cuenta o mediante políticas.

Para nuevos entornos es recomendable exigir IMDSv2 siempre que las aplicaciones y AMIs sean compatibles.

Placement Groups

Los Placement Groups permiten controlar cómo se distribuyen físicamente las instancias EC2.

Existen tres estrategias principales.

Cluster

Coloca las instancias físicamente cerca.

Adecuado para:

  • baja latencia;
  • alto throughput;
  • HPC.

Normalmente opera dentro de una única Availability Zone.

Spread

Distribuye las instancias sobre hardware diferente para reducir fallos correlacionados.

Puede abarcar múltiples Availability Zones.

Un Spread Placement Group a nivel de rack soporta actualmente un máximo de 7 instancias en ejecución por Availability Zone.

Partition

Divide las instancias entre distintas particiones físicas.

Es adecuado para sistemas distribuidos como:

  • HDFS;
  • HBase;
  • Cassandra.

Una partición no comparte racks con las demás, reduciendo el impacto de determinados fallos de hardware.

Amazon EFS

Amazon Elastic File System proporciona almacenamiento de archivos administrado y elástico.

A diferencia de EBS, EFS es almacenamiento de archivos, no almacenamiento de bloques.

Utiliza:

  • NFSv4.0;
  • NFSv4.1.

AWS recomienda normalmente NFSv4.1 cuando sea compatible.

Características:

  • sistema de archivos compartido;
  • múltiples clientes simultáneos;
  • escalado automático;
  • pago según capacidad utilizada;
  • integración con IAM;
  • mount targets dentro de la VPC.

Regional y One Zone

Actualmente EFS dispone de dos tipos principales de sistema de archivos.

Regional

Los datos se almacenan redundantemente entre múltiples Availability Zones de una región.

Es la opción recomendada cuando necesitamos alta disponibilidad.

One Zone

Almacena los datos dentro de una única Availability Zone y ofrece un coste menor, pero no protege frente a la pérdida completa de dicha AZ.

Storage Classes

EFS dispone actualmente de:

  • Standard
  • Infrequent Access (IA)
  • Archive

Lifecycle Management puede mover automáticamente archivos entre clases según cuándo fueron accedidos por última vez.

Throughput

EFS dispone actualmente de tres modos de throughput:

  • Elastic
  • Provisioned
  • Bursting

Elastic Throughput permite que AWS adapte automáticamente el throughput según la actividad del filesystem.

FSx for Lustre

Amazon FSx for Lustre continúa siendo el servicio gestionado de AWS para ejecutar el sistema de archivos Lustre.

Está pensado para workloads donde el rendimiento del almacenamiento es crítico:

  • machine learning;
  • HPC;
  • análisis;
  • procesamiento de vídeo;
  • modelado financiero;
  • Electronic Design Automation.

FSx for Lustre puede integrarse directamente con Amazon S3, presentando los objetos almacenados en un bucket como archivos dentro del filesystem y permitiendo posteriormente exportar resultados de nuevo a S3.

EC2 Auto Scaling

Amazon EC2 Auto Scaling permite mantener y ajustar automáticamente la cantidad de instancias EC2 de una aplicación.

Un Auto Scaling Group dispone normalmente de:

  • capacidad mínima;
  • capacidad máxima;
  • capacidad deseada.

Podemos escalar:

  • manualmente;
  • siguiendo un horario;
  • mediante métricas;
  • utilizando políticas dinámicas;
  • mediante predictive scaling.

Launch Templates

Para lanzar las instancias de un Auto Scaling Group debemos utilizar actualmente Launch Templates.

Los antiguos Launch Configurations están siendo retirados progresivamente:

  • desde 2023 no soportan nuevos tipos de instancia;
  • cuentas creadas desde junio de 2023 no pueden crearlos desde la consola;
  • cuentas creadas desde octubre de 2024 no pueden crear nuevos Launch Configurations mediante ningún método.

AWS recomienda migrarlos a Launch Templates.

Los Launch Templates permiten además:

  • versionado;
  • múltiples tipos de instancia;
  • Spot + On-Demand;
  • nuevas generaciones de EBS;
  • Capacity Reservations;
  • configuración moderna de metadata;
  • nuevas funcionalidades EC2.

Scaling policies

Actualmente las estrategias dinámicas más importantes son:

Target Tracking

Definimos un valor objetivo para una métrica y Auto Scaling intenta mantenerlo.

Por ejemplo:

Average CPU = 50 %

AWS recomienda Target Tracking para muchos escenarios porque simplifica enormemente las políticas de escalado.

Step Scaling

Permite realizar diferentes acciones dependiendo de cuánto se haya superado un threshold.

Por ejemplo:

  • CPU > 60 % → +1 instancia;
  • CPU > 80 % → +3 instancias.

Simple Scaling

Continúa existiendo, pero AWS recomienda utilizar Target Tracking o Step Scaling en lugar de Simple Scaling para nuevos diseños.

Tipos de ajuste

En Step Scaling podemos utilizar:

ChangeInCapacity

Añade o elimina una cantidad determinada.

Ejemplo:

3 instancias + 2 = 5

ExactCapacity

Establece directamente la capacidad deseada.

Ejemplo:

desired capacity = 5

PercentChangeInCapacity

Incrementa o reduce la capacidad mediante un porcentaje.

Cooldown y warmup

El cooldown por defecto continúa siendo de 300 segundos cuando se utilizan Simple Scaling Policies.

Sin embargo, AWS recomienda actualmente utilizar mecanismos de instance warmup junto con Target Tracking o Step Scaling en lugar de diseñar nuevas arquitecturas alrededor de Simple Scaling y cooldowns.

Rebalanceo entre Availability Zones

Auto Scaling intenta mantener las instancias distribuidas entre las Availability Zones configuradas.

Durante determinadas operaciones de rebalanceo puede lanzar nuevas instancias antes de eliminar las antiguas.

Por ello, temporalmente el Auto Scaling Group puede superar su capacidad máxima aproximadamente en un 10 % o una instancia, el valor que sea mayor.

Default Termination Policy

La política de terminación por defecto ha cambiado respecto a las explicaciones antiguas basadas en buscar la instancia más próxima a la siguiente hora de facturación.

Actualmente EC2 Auto Scaling intenta principalmente:

  1. mantener el equilibrio entre Availability Zones;
  2. eliminar instancias que utilicen configuraciones antiguas;
  3. aplicar posteriormente el resto de criterios de terminación.

Esto es especialmente importante ahora que los Auto Scaling Groups utilizan Launch Templates versionados.

La política ClosestToNextInstanceHour continúa existiendo como política específica, pero ya no debe describirse como el comportamiento fundamental de la política por defecto.

EC2 Instance Connect

EC2 Instance Connect permite administrar el acceso SSH a instancias EC2 utilizando IAM.

Entre otras cosas permite:

  • utilizar claves SSH temporales;
  • centralizar autorización mediante IAM;
  • auditar operaciones mediante AWS CloudTrail;
  • reducir la necesidad de distribuir claves SSH permanentes.

Ya no debemos describirlo como un «nuevo servicio de 2019»: actualmente forma parte consolidada del ecosistema EC2.

Además existe EC2 Instance Connect Endpoint, que permite conectarse a instancias mediante SSH o RDP sin que estas necesiten disponer de una IP pública.

Conclusión

Servicios como EC2, EBS, EFS, Elastic Load Balancing y Auto Scaling siguen siendo piezas fundamentales para diseñar arquitecturas en AWS.

Sin embargo, muchas de las prácticas habituales hace unos años han cambiado.

Hoy debemos pensar principalmente en:

  • Savings Plans frente a antiguas estrategias de Reserved Instances.
  • Capacity Reservations cuando realmente necesitamos capacidad garantizada.
  • Auto Scaling o EC2 Fleet en lugar de Spot Fleet.
  • price-capacity-optimized para Spot.
  • Launch Templates en lugar de Launch Configurations.
  • gp3 e io2 como generaciones actuales de EBS.
  • ALB, NLB y GWLB en lugar de Classic Load Balancer.
  • Security Groups también en Network Load Balancer.
  • IMDSv2 para acceder de forma segura a Instance Metadata.
  • EFS Regional, One Zone, IA y Archive.
  • health checks, Auto Scaling y recuperación automática como mecanismos básicos de resiliencia.

AWS evoluciona constantemente, por lo que revisar material antiguo antes de utilizarlo para preparar una certificación resulta casi tan importante como estudiar los propios conceptos.

Links de interés

¿Te ha ayudado este artículo?

☕ Invítame a un café

Un comentario de “AWS Solutions Architect Associate (SAA) 2018 – III”

  1. Pingback: AWS certifications posts

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Rubenortiz.es
Powered by  GDPR Cookie Compliance
Información sobre privacidad

Este sitio web utiliza cookies para ofrecerte la mejor experiencia de usuario posible. La información sobre cookies se almacena en tu navegador y realiza funciones como reconocerte cuando vuelve a nuestro sitio web y ayudarme a comprender qué secciones de la web resultan más interesantes y útiles.