Fundamentos de la Infraestructura Global de AWS

1

Conceptos Fundamentales de AWS y la Nube

2

Registro y uso de la consola de AWS para servicios en la nube

3

Seguridad en AWS: Prácticas Esenciales y Gestión de Accesos

4

Modelo de Responsabilidad Compartida en AWS: Seguridad y Cumplimiento

5

Creación y gestión de usuarios en AWS IAM

6

Regiones y Zonas de Disponibilidad en AWS

7

Infraestructura Global de AWS: Local Zones, Outposts y Edge Locations

8

Gestión de DNS y dominios con AWS Route 53

Quiz: Fundamentos de la Infraestructura Global de AWS

Redes en AWS

9

Componentes y configuración de una VPC en AWS

10

Seguridad en VPC: Grupos de Seguridad y Network ACLs

11

Creación de una VPC en AWS: Paso a Paso Práctico

12

Creación de VPC en AWS: Internet Gateway y NAT Gateway

13

Opciones de Conectividad en AWS: VPN y DirectConnect

14

Servicios Perimetrales en AWS: CloudFront y Global Accelerator

Quiz: Redes en AWS

Servicios de cómputo en AWS

15

Fundamentos de Amazon EC2: Servidores Virtuales en la Nube

16

Creación de un Servidor Web en AWS Paso a Paso

17

Conexión a Servidor AWS EC2 usando SSH en Mac y Linux

18

Conexión a Servidor con PuTTY en Windows

19

Instalación de un Servidor Web Apache en AWS EC2

20

Tipos de Instancias EC2 y Casos de Uso en AWS

21

Comparación de precios y tipos de instancias EC2 en AWS

22

Servicios de Contenedores en AWS: Docker, ECS, EKS y Fargate

23

Conceptos Básicos de Serverless y AWS Lambda

Quiz: Servicios de cómputo en AWS

Balanceo de Carga y Auto escalamiento

24

Balanceo de Carga en AWS: Tipos y Usos Prácticos

25

Autoescalamiento en AWS: Gestión Dinámica de Recursos en la Nube

26

Implementación de Aplicación Web en AWS con Alta Disponibilidad

27

Conexión y Configuración de Servidores en AWS EC2

28

Configuración de Balanceador de Carga en AWS EC2

29

Eliminación de Recursos en AWS: EC2, VPC y NAT Gateway

Almacenamiento en AWS

30

Opciones de Almacenamiento en la Nube con AWS

31

Tipos de almacenamiento en AWS: bloques, archivos y objetos

32

Almacenamiento y Seguridad en Amazon S3: Uso y Configuración

33

Clases de Almacenamiento en Amazon S3: Usos y Características

34

Migración de Datos a AWS con Snow Family y Amazon S3

35

Creación y Configuración de Buckets en Amazon S3

36

Gestión de Buckets y Versionamiento en Amazon S3

37

Almacenamiento y gestión de volúmenes EBS en AWS

38

Tipos de volúmenes EBS y sus casos de uso en AWS

39

Almacenamiento de Archivos en AWS: EFS y FSx

40

Almacenamiento Híbrido con AWS Storage Gateway

Quiz: Almacenamiento en AWS

Bases de datos en AWS

41

Creación y Gestión de Bases de Datos Relacionales en AWS

42

Bases de Datos en AWS: Relacionales vs No Relacionales

43

Creación de una Base de Datos MySQL en AWS Paso a Paso

44

Conexión y gestión de bases de datos MySQL en AWS con DBeaver

45

Introducción a DynamoDB: Características y Ventajas en AWS

46

Creación y Configuración de Tablas en DynamoDB

Quiz: Bases de datos en AWS

Seguridad en AWS

47

Seguridad en AWS: Protección de Recursos y Aplicaciones en la Nube

48

Gestión de Roles, Grupos y Políticas en AWS IAM

49

Protección contra ataques DDoS con AWS Shield y WAF

50

Administración de Llaves de Seguridad en AWS KMS y CloudHSM

51

Creación y uso de llaves KMS en AWS paso a paso

52

Gestión de Secretos en AWS con Amazon Secrets Manager

53

Seguridad en AWS: Artifact, GuardDuty, Inspector y Config

54

Monitoreo y Auditoría de Recursos AWS: CloudTrail y AWS Config

55

Servicios de Seguridad en AWS: Amazon Macie, Security Hub y más

Quiz: Seguridad en AWS

Costos en AWS

56

Modelos de Precios y Costos en AWS: Comprensión y Estrategias

57

Análisis de Costos en AWS con Cost Explorer

58

Gestión de Presupuestos con AWS Budgets

59

Costos de Infraestructura: On-Premises vs Nube y Herramientas AWS

60

Creación de alertas de presupuesto en AWS

61

Ahorro en AWS: Estrategias con Saving Plans para EC2 y Computación

62

Planes de Soporte AWS: Diferencias y Selección Adecuada

63

Frameworks AWS: Well-Architected y Cloud Adoption

Quiz: Costos en AWS

Servicios Complementarios

64

Gestión Multicuenta en AWS con Control Tower y Organizations

65

Amazon QuickSight: Creación de Dashboards Inteligentes en AWS

66

Servicios de Machine Learning en AWS: Amazon Comprehend y más

67

Principales Servicios de Desarrollo en AWS

68

Servicios Avanzados de AWS para Aplicaciones Modernas y Seguras

Quiz: Servicios Complementarios

Migracion a la nube de AWS

69

Estrategias de Migración a la Nube: Las 7 R's de AWS

70

Estrategias de Migración a la Nube para Aplicaciones Web

71

Migración de Bases de Datos con Database Migration Service

72

Migración de Datos a AWS con DataSync

Quiz: Migracion a la nube de AWS

Cómo aprobar la certificación AWS Cloud Practitioner

73

Certificaciones AWS: Niveles y Especializaciones

74

Detalles del Examen AWS Cloud Practitioner

75

Dominios del Examen AWS Cloud Practitioner: Enfoque y Estrategias

76

Agendar Examen AWS Cloud Practitioner: Guía Paso a Paso

77

Compra y Distribución de Vouchers AWS con XVoucher

78

Tipos de Preguntas en el Examen AWS Cloud Practitioner

79

Consejos para Aprobar el Examen AWS Cloud Practitioner

80

Rutas de carrera tras certificarte como AWS Cloud Practitioner

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Curso AWS Cloud Practitioner Certification

Curso AWS Cloud Practitioner Certification

Carlos Andrés Zambrano Barrera

Carlos Andrés Zambrano Barrera

Configuración de Balanceador de Carga en AWS EC2

28/80
Recursos

¿Cómo configurar un balanceador de carga en AWS?

La implementación de un balanceador de carga de aplicaciones (Application Load Balancer o ALB) en AWS es crucial para distribuir equitativamente el tráfico entre varias instancias. Este proceso es esencial para mejorar tanto la disponibilidad como la resiliencia de aplicaciones en la nube. En este artículo, exploraremos detalladamente cómo configurar un ALB, paso a paso, utilizando la consola de AWS.

¿Cuál es el balanceador de carga adecuado a utilizar?

AWS ofrece diversas opciones de balanceadores, cada uno destinado para diferentes propósitos:

  • Application Load Balancer (ALB): Ideal para aplicaciones web, operando a nivel capa 7.
  • Network Load Balancer (NLB): Diseñado para aplicaciones que requieren realizar un balanceo de carga a nivel capa 4.
  • Gateway Load Balancer (GLB): Se utiliza principalmente para ejecutar tareas que requieran la integración con firewalls y herramientas de seguridad.

Para aplicaciones web, especialmente aquellas que manejan tráfico HTTP/HTTPS, el ALB es el más adecuado.

¿Cómo se configura un Application Load Balancer?

  1. Navegar a EC2 en la consola de AWS:

    • Desde la consola de AWS, buscar y seleccionar "EC2" en el menú.
    • En el lado izquierdo, seleccionar la opción "Load Balancers".
    • Hacer clic en "Create Load Balancer".
  2. Seleccionar el tipo de balanceador de carga:

    • Elegir "Application Load Balancer" y hacer clic en "Create".
    • Nombrar el balanceador, por ejemplo, "mi-primer-ALB".
    • Elegir si será público o privado; en este caso, seleccionar "internet facing".
    • Seleccionar el tipo de dirección IP, aquí trabajamos con "IPv4".
  3. Configurar las subredes y VPC:

    • Cambiar la VPC por "mi primer VPC".
    • Seleccionar las subredes en las zonas de disponibilidad adecuadas (Pública 1 y Pública 2).
  4. Configurar el Security Group:

    • Crear un nuevo grupo de seguridad (Security Group), por ejemplo, "SG-ALB".
    • Añadir reglas para permitir tráfico HTTP desde cualquier dirección IP.
  5. Definir parámetros del listener:

    • Un "listener" es dónde el ALB 'escucha' tráfico entrante; configurar para que el ALB escuche por el puerto HTTP 80.
  6. Crear un grupo de destino (Target Group):

    • Definir cómo se manejan los destinatarios del tráfico (instancias).
    • Nombrar el grupo de destino, por ejemplo, "mi-primer-target".
    • Configurar el Health Check para verificar el estado de las instancias.

¿Cómo asegurar que las instancias están saludables?

El balanceador utiliza Health Checks para comunicarse con las instancias:

  • Healthy Threshold: Define el número de respuestas positivas necesarias para declarar una instancia como saludable.
  • Unhealthy Threshold: Número de respuestas negativas antes de considerarla no saludable.
  • Timeout: Tiempo que espera el balanceador antes de parar de enviar tráfico si la instancia no responde.
  • Intervalo: Tiempo entre cada Health Check.
  • Respuesta esperada: Un HTTP 200 indica que la instancia está funcionando correctamente.

¿Qué hacer después de configurar el balanceador?

Volver al Load Balancer en la consola, actualizar las instancias en el Target Group y confirmar que están saludables. Si una de las instancias no es saludable, asegúrese de que las reglas del Security Group están correctamente configuradas para aceptar el tráfico desde el ALB.

¿Cómo comprobar que la configuración es correcta?

Después de que el ALB esté activo, copiar el DNS proporcionado por AWS e ingresarlo en un navegador web. Al actualizar repetidamente la página, se debería observar que el tráfico se distribuye equitativamente entre las instancias configuradas.

¿Qué implicaciones tiene detener una instancia?

Detener una instancia debe reflejarse en el balanceador. Si una instancia deja de estar saludable, el ALB redirige automáticamente todo el tráfico a las instancias restantes que estén saludables.

Este proceso no solo mejora la distribución del tráfico, sino que también asegura la disponibilidad de las aplicaciones, minimizando riesgos de caídas. Sigue explorando y profundizando en esta tecnología para maximizar tus recursos en la nube. ¡Adelante, el conocimiento es poder!

Aportes 14

Preguntas 2

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Esta clase es una joya, me gusta mucho la combinacion gráfica de la arquitectura con los flujos de conexion en la consola de aws!
Usaremos de aplicación por que será HTTP/HTTPS JAMAS Utilizaremos el clásico
Entiendo que esto puede ser con fines didacticos, pero como son servidores privados, no deberian ser accesibles desde el internet. Una architectura como la siguiente seria más segura ![](https://static.platzi.com/media/user_upload/image-98454510-d855-408b-aec2-b25ac9c7fbe8.jpg) Donde tenemos 2 load balancers distribuidos en servers en 2 AZs
1:40 > Clásic Load Balancer
A mí me paso que, mientras se detenía el server b, arrojaba un 504 cuando intentaba mandar a ese server pero solo fue hasta que apareció como estatus "detenido". Ya después todo bien.
## **Beneficios de Alta Disponibilidad y Health Checks** ✅ **Menos tiempo de inactividad** – Instancias fallidas se reemplazan automáticamente. ✅ **Escalabilidad automática** – Se ajusta la cantidad de servidores según la demanda. ✅ **Reducción de costos** – Solo se usan recursos cuando se necesitan. ✅ **Carga distribuida** – Un Load Balancer previene la sobrecarga de un solo servidor.
Al balanceador clásico es el que no hay que escoger
El que se debe crear es el ALB, el que no es el Clásico
Hola amigos, tengo el siguiente erroe: ![](https://static.platzi.com/media/user_upload/image-e842f21e-ab27-45d3-8733-0c34b7ad9c0e.jpg)alguien podria decirme que puede esta sucediendo mal ?, porfa quiero completar el curso, agradeceria un monton de su ayuda
**Siempre me pregunté cómo Platzi maneja múltiples apps bajo la misma URL.** Al revisar el **Load Balancer**, descubrí que se pueden crear **reglas específicas** para que rutas como **/account** apunten a un **targetGroup** con la **versión antigua** de la aplicación, ![](https://static.platzi.com/media/user_upload/image-372b3470-b0e4-416b-9beb-34a2ea84200c.jpg) mientras que el resto del tráfico va a la **nueva versión**. Esto permite realizar **migraciones graduales**: por ejemplo, algunas partes del sistema siguen usando la **versión vieja** mientras que otras ya están migradas a la nueva, sin afectar la experiencia del usuario. **Nota:** No estoy 100% seguro de que Platzi lo haga de esta manera, pero al observar el uso de **diferentes versiones de React** en distintas secciones, parece que utilizan una estrategia similar para migrar poco a poco las apps. **¿Si hay algún profesor de Platzi que pueda confirmar o darnos más detalles sobre cómo manejan esto?** ¡Sería genial tener una idea más clara!
Cuando se detiene el **<u>Servidor A</u>**, mas que dar ***Unhealthy***, creo que lo detecta como ***Unused***. * Total Targets: 2 * Healthy: 1 * Unhealthy: 0 * Unused: 1 Me hace mas sentido.
El tiempo que es suficiente para ver reflejado cuantos servidores son unhealthy es (# Healthy Threshold) x (Timeout + Interval) - Interval Es decir, cada check espera la respuesta un tiempo (Timeout) y entre cada check se toma otro tiempo (Interval) Eso lo hace tantas veces como checks que especifiquemos y en el ultimo check no hay mas Intervalo de espera pues no hay mas checks que ver ![](https://static.platzi.com/media/user_upload/image-d4371205-a624-46cf-b259-14d4629e0097.jpg)
Muy fan de las explicaciones graficas del profe
a mi me sale el servidor B como unhealthy :(