Forem: Javier Madriz

Domina la Conectividad Privada en AWS con VPC Endpoints (¡Ahorra $/mes!)

Javier Madriz — Fri, 27 Mar 2026 14:42:50 +0000

Bienvenidos a una nueva entrega en el maravilloso mundo de las redes en AWS.

Muchos arquitectos caen en la trampa de desplegar un NAT Gateway solo para que sus servidores privados se comuniquen con servicios como Amazon S3 y DynamoDB. Esto no solo infla la factura, sino que puede resultar contraproducente si nuestro objetivo es mantener los recursos 100% aislados del mundo exterior. Por eso, hoy vamos a construir una arquitectura de conectividad privada, segura y, lo mejor de todo, con un costo de red de $0.

Es posible tener lo mejor de ambos mundos: seguridad extrema y ahorro total?

Arquitectura base

Para que este workshop sea fluido y nos enfoquemos en lo que realmente importa asegurar la conectividad privada entre nuestros servidores y servicios como S3 y DynamoDB he diseñado una plantilla de CloudFormation. Con ella, podrás desplegar en minutos la infraestructura base que incluye:

VPC: Una red virtual aislada con una subred 100% privada (sin Internet Gateway).
Tabla de Rutas: Asociada específicamente a nuestra subred privada.
Instancia EC2: Un servidor sin dirección IP pública (totalmente invisible desde internet).
Recursos de Datos: Un Bucket de Amazon S3 y una Tabla de Amazon DynamoDB listos para ser consumidos.
Seguridad IAM: Un rol con el principio de mínimos privilegios para interactuar con S3 y DynamoDB de forma segura.
Security Group: Configurado específicamente para nuestra instancia EC2.

💡 Nota de Arquitecto: Al no tener un Internet Gateway, nuestra instancia nace "ciega y sorda" hacia el exterior. Es el escenario perfecto para probar cómo los VPC Endpoints actúan como túneles privados dentro de la red global de AWS.

💡 Nota: Si te apasionan las redes y prefieres construir cada componente desde cero, en mi perfil de dev.to tengo exactamente lo que necesitas. He preparado dos workshops previos donde te explico paso a paso cómo crear una VPC, subredes, tablas de rutas y mucho más:

Si ya lo tienes controlado, crea el stack con la plantilla que preparé para ti y te dejo a continuación.

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Workshop Base: Red Privada Aislada para Práctica de VPC Endpoints'

Parameters:
  VpcCIDR:
    Type: String
    Default: 10.0.0.0/24
    Description: CIDR para la VPC del Workshop

  PrivateSubnetCIDR:
    Type: String
    Default: 10.0.0.0/25
    Description: CIDR para la Subred Privada (128 IPs)

  LatestImageId:
    Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
    Default: '/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-6.1-x86_64'


Resources:
  # --- INFRAESTRUCTURA DE RED ---
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 
        Ref: VpcCIDR
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: Workshop-VPC-Endpoint

  PrivateSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: 
        Ref: VPC
      CidrBlock: 
        Ref: PrivateSubnetCIDR
      AvailabilityZone:
        Fn::Select:
          - 0
          - Fn::GetAZs: ""
      MapPublicIpOnLaunch: false # Crucial: Asegura que ningun recurso se lance con ip publica
      Tags:
        - Key: Name
          Value: Subred-Aislada

  PrivateRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId:
        Ref: VPC
      Tags:
        - Key: Name
          Value: Tabla-Ruteo-Privada

  SubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: 
        Ref: PrivateSubnet
      RouteTableId:
        Ref: PrivateRouteTable

  # --- SEGURIDAD (IAM) ---
  EC2InstanceRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: [ec2.amazonaws.com]
            Action: ['sts:AssumeRole']
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
        - arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess
      Policies:
        - PolicyName: EC2ConnectPolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - ec2-instance-connect:SendSSHPublicKey
                Resource:
                  Fn::Sub: "arn:${AWS::Partition}:ec2:${AWS::Region}:${AWS::AccountId}:instance/*"

  EC2InstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      Roles:
       - Ref: EC2InstanceRole

  # --- SEGURIDAD (Security Groups) ---
  InstanceSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Permite SSH solo desde el CIDR de la VPC (temporalmente)
      VpcId:
        Ref: VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp:
            Ref: VpcCIDR # Permitimos traficos desde la red interna

  # --- CÓMPUTO ---
  WorkshopInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      IamInstanceProfile:
        Ref: EC2InstanceProfile
      ImageId:
        Ref: LatestImageId
      SubnetId:
        Ref: PrivateSubnet
      SecurityGroupIds:
        - Ref: InstanceSecurityGroup
      Tags:
        - Key: Name
          Value: EC2-Privada-Workshop

  # --- RECURSOS DE DATOS (Para las pruebas) ---
  WorkshopBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: 
        Fn::Sub: 'workshop-s3-endpoint-${AWS::AccountId}-${AWS::Region}'
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

  WorkshopTable:
    Type: AWS::DynamoDB::Table
    DeletionPolicy: Delete
    Properties:
      TableName: Workshop-Dynamo-Endpoint
      AttributeDefinitions:
        - AttributeName: ID
          AttributeType: S
      KeySchema:
        - AttributeName: ID
          KeyType: HASH
      BillingMode: PAY_PER_REQUEST

Outputs:
  VpcId:
    Value:
      Ref: VPC
  SubnetId:
    Value:
      Ref: PrivateSubnet
  RouteTableId:
    Value:
      Ref: PrivateRouteTable
  BucketName:
    Value:
      Ref: WorkshopBucket

🚀 Despliegue de la infraestructura

Esta plantilla está diseñada para que la puedas desplegar en cualquier región. Yo personalmente estaré trabajando en Ohio (us-east-2); ya saben, para no estar tan "amorochados" en Virginia con el resto del mundo 😉.

Para lanzar el laboratorio, sigue estos pasos:

Copia el código YAML de arriba y guárdalo en tu editor favorito con el nombre base-stack.yaml.
Ve a la consola de AWS CloudFormation y selecciona Create stack > With new resources (standard).
En la sección de Template source, elige Upload a template file y sube tu archivo.
Asigna un nombre al stack (ej. Workshop-VPC-Endpoints) y deja los parámetros por defecto.
Haz clic en Next hasta llegar al final, marca la casilla de "I acknowledge that AWS CloudFormation might create IAM resources" y presiona Submit.

Al finalizar la creación (después de unos 2 o 3 minutos), deberías ver el estado como: CREATE_COMPLETE.

Plan de batalla 🎯.

Para conquistar este laboratorio, nos dividiremos en tres objetivos estratégicos:

Misión 1: El Rescate (EIC Endpoint). Aprenderemos a entrar a nuestra instancia privada mediante EC2 Instance Connect (EIC) Endpoint. Olvídate de gestionar llaves .pem perdidas, de configurar un Bastion Host o de exponer tu servidor con una IP pública.
Misión 2: El Túnel de Objetos (S3 Gateway Endpoint). Configuraremos un acceso directo hacia Amazon S3. Veremos cómo podemos acceder a nuestros objetos sin que un solo paquete de datos toque la internet publica.
Misión 3: El Almacén de Datos (DynamoDB Gateway Endpoint). Estableceremos una conexión privada hacia nuestra base de datos NoSQL para asegurar que el tráfico de nuestra aplicación nunca salga de la red de AWS.

🛡️ Nota de Arquitecto: Aunque ambos son "Endpoints", en las misiones 2 y 3 usaremos el tipo Gateway, que es un recurso gratuito y funciona mediante rutas en nuestra VPC, a diferencia del tipo Interface que usa direcciones IP privadas (ENI).

Misión 1: Rescate de la Instancia Privada (EIC Endpoint)

Si nos dirigimos a la consola de Amazon EC2, seleccionamos la instancia que desplegamos con nuestra plantilla de CloudFormation e intentamos conectarnos a ella utilizando el botón "Connect", nos toparemos con un muro de advertencias:

"No public IPv4 or IPv6 address assigned."

"Instance is not in a public subnet."

AWS nos está confirmando que nuestra arquitectura de aislamiento funciona: la instancia no tiene "puertas" hacia el exterior. Tradicionalmente, aquí es donde muchos se rinden y crean un Bastion Host (un servidor extra que hay que pagar y parchar).

En resumidas cuentas, en este momento no podemos conectarnos a nuestra instancia. Pero no te preocupes, que para esto (y casi todo lo demás) existe... no, no es MasterCard 😉, es EC2 Instance Connect (EIC) Endpoint. Afortunadamente, contamos con esta funcionalidad que nos permite conectarnos a nuestros servidores en subredes privadas, incluso cuando están totalmente aislados del exterior.

Para configurarlo, sigamos estos pasos:

Dirígete al servicio de VPC en la consola de AWS.
En la columna de la izquierda, busca la sección PrivateLink and Lattice.
Selecciona Endpoints y luego haz clic en el botón Create endpoint.

🛠️ Configuración del Endpoint: El "Apretón de Manos"

Al crear el endpoint, nos encontraremos con varios campos. Vamos a desglosarlos para que no haya pérdida:

Name: EIC-Connect (o el que prefieras).
Type, Category: Selecciona EC2 Instance Connect Endpoint.
VPC: Elige nuestra VPC del workshop: Workshop-VPC-Endpoint.

⚠️ Un pequeño paréntesis: El Security Group del Endpoint
Antes de terminar, necesitamos un Security Group (SG) específico para nuestro EIC. Este actuará como el "permiso de salida" para que el túnel llegue a la instancia.

Crea un nuevo SG con estos datos:

Name: SG-EIC-Endpoint
VPC: Workshop-VPC-Endpoint
Outbound Rule (Regla de Salida): Es la única que necesitamos.
Protocolo: TCP
Puerto: 22 (SSH)
Destino: 10.0.0.0/25 (El CIDR de nuestra subred privada).

💡 Tip de Arquitecto: Usamos el CIDR 10.0.0.0/25 para que este endpoint nos sirva para cualquier instancia que lancemos en nuestra subred privada. Si quisiéramos ser ultra-estrictos (Zero Trust), en el Destino podríamos poner directamente el ID del Security Group de la instancia.

Listo! Con el Security Group creado, regresemos a la pestaña de creación del Endpoint:

En el apartado de Security groups, haz clic en el ícono de refrescar para que aparezca nuestro recién creado SG-EIC y selecciónalo.
En la sección de Subnet, selecciona la subred privada de nuestra VPC, asegúrate de que esté marcada la opción IPv4 y haz clic en Create endpoint.

La creación del recurso puede tomar un par de minutos. Mientras esperas, puedes tomar un café ☕. En cuanto veas el estado (Status) como Available, significa que nuestro túnel privado está listo para operar y conectarnos a la instancia.

A continuación, te dejo una imagen de referencia con la configuración completa del EIC Endpoint:

Misión 1: ¡Conexión Exitosa! 🚀

¡Llegó el momento de la verdad! Vamos a entrar a nuestra instancia privada sin necesidad de una IP pública:

Regresa al servicio de Amazon EC2 y selecciona tu instancia.
Haz clic en el botón Connect.
En las pestañas superiores, selecciona EC2 Instance Connect.
En la sección de Connection Type, elige la opción: Connect using a Private Ip (EC2 Instance Connect Endpoint).
En el menú desplegable de EC2 Instance Connect Endpoint, selecciona el Endpoint que creamos (EIC-Connect).
Finalmente, haz clic en Connect.

En este punto, ya deberíamos estar dentro de nuestro servidor EC2 sintiéndonos como auténticos hackers 💻. Ver ese prompt de la terminal después de haber pasado por una red 100% privada es la prueba de que nuestro túnel seguro funciona a la perfección.

Hasta este punto, no tenemos ninguna comunicación establecida con Amazon S3 ni con DynamoDB. Como nuestra instancia está en una subred privada sin salida a internet, ¿qué crees que pasaría si intentamos listar nuestros recursos desde la AWS CLI?

¡Hagamos la prueba de fuego! Ejecuta estos comandos en tu terminal:

# Intento de listar buckets
aws s3 ls

# Intento de listar tablas, pásale al comando la región en la que estas trabajando.
aws dynamodb list-tables --region us-east-2

¿Qué sucede? Exacto: Silencio total. La terminal se quedará "congelada" intentando alcanzar los endpoints públicos de AWS hasta que finalmente recibas un Connection Timeout.

💡 Explicación: Aunque los servicios de AWS son internos a la red de Amazon, sus APIs (los puntos a los que llamamos por CLI) residen en el internet público. Como nuestra instancia es "tímida" y no tiene salida al exterior, no sabe cómo llegar a ellos. De hecho, te invito a que revises la tabla de rutas "Tabla-Ruteo-Privada" creada por nuestro stack: notarás que no existe ninguna ruta (ni un Internet Gateway ni un NAT Gateway) que le indique al tráfico hacia dónde ir. Para nuestra instancia, el resto del mundo no existe... todavía.

Así que, para lograr nuestro objetivo de conectividad total sin comprometer la seguridad, vamos a implementar los Gateway Endpoints tanto para S3 como para DynamoDB.

Misión 2: Misión 2: El Túnel Privado para Amazon S3

Un Gateway Endpoint es, en esencia, un puente privado que creamos dentro de nuestra VPC para comunicarnos con los servicios de AWS sin que los datos salgan jamás de la red interna de Amazon. Es decir: logramos un contacto cero con el internet público.

A diferencia de otros tipos de endpoints, el de tipo Gateway no utiliza direcciones IP privadas en tu subred; en su lugar, funciona mediante "Prefix Lists" (listas de prefijos) que se añaden automáticamente a tu Tabla de Rutas.

💰 Dato para tu bolsillo: Los Gateway Endpoints para S3 y DynamoDB son gratuitos. No hay cargos por hora.

Regresa al servicio de VPC y, en la columna izquierda, selecciona Endpoints seguido del botón "Create endpoint".
En Service category, asegúrate de que esté seleccionado AWS services.
En la barra de búsqueda de Services, escribe: Gateway.
¡Punto Crucial! Busca el servicio que termina en .s3 y asegúrate de que el Type sea Gateway..

Nota: También verás uno de tipo "Interface", pero esa es harina de otro costal (y tiene costo). Quédate con el Gateway, que es el héroe gratuito de esta historia.

En el desplegable de VPC, selecciona nuestra: Workshop-VPC-Endpoint.
Configuración de Red: Aquí debes marcar el check de nuestra Tabla-Ruteo-Privada.

¿Por qué? Al hacer esto, CloudFormation (o la consola) agregará automáticamente una ruta "mágica" que dice: "Todo el tráfico que vaya hacia S3, envíalo por este túnel privado". Sin esto, tu instancia seguirá gritando al vacío.

Para finalizar, haz clic en Create endpoint.

Esto puede tardar un par de minutos en aparecer como Available. Mientras tanto, ¡aprovechemos el tiempo!

Podemos adelantar la Misión 3: El Almacén de Datos (DynamoDB Gateway Endpoint) siguiendo exactamente los mismos pasos que acabamos de realizar. La única diferencia es que, en la barra de búsqueda de servicios, esta vez seleccionarás el que termina en .dynamodb (asegurándote de que el tipo sea Gateway).

No olvides asociarlo también a nuestra Tabla-Ruteo-Privada para que la magia de las rutas se aplique a ambos servicios.

Con nuestros Gateway Endpoints en estado Available, ha llegado el momento de volver a la terminal y reclamar nuestra victoria. Vamos a intentar listar de nuevo nuestro bucket de S3 y nuestra tabla de DynamoDB para confirmar que la comunicación fluye por el túnel privado:

🔍 Ahora puedes volver a nuestra Tabla-Ruteo-Privada y notarás que la magia ha sucedido: han aparecido dos nuevas rutas con identificadores que empiezan por pl-xxxxxxxx (Prefix Lists). Estas entradas apuntan directamente hacia S3 y DynamoDB.

Esas rutas son las que le indican a tu subred: "Si alguien pregunta por estos servicios, no busques en internet; envíalo por el túnel privado". ¡El camino ya está despejado!

# Listar Buckets de S3
aws s3 ls

# Listar Tablas de DynamoDB, no olvides colocar tu región
aws dynamodb list-tables --region us-east-2

¡Yeahhh! 🚀 Si ves el nombre de tu bucket y de tu tabla en pantalla, ¡felicidades! Acabas de establecer una conexión privada, segura y, lo más importante, totalmente gratuita.

🧠 ¿Qué pasó tras bastidores? Cuando ejecutaste los comandos, tu VPC consultó la Tabla de Rutas, vio que el destino era S3/DynamoDB y, en lugar de intentar salir a internet, envió el tráfico directamente a través del Endpoint correspondiente para cada servicio. ¡Magia de redes en su máxima expresión!

¡Todo ha salido a la perfección! Ahora contamos con una arquitectura robusta y segura donde una instancia EC2, totalmente aislada en una subred privada y sin IP pública, puede comunicarse fluidamente con nuestros servicios de Amazon S3 y DynamoDB.

Partiendo de aquí, el cielo es el límite. Ustedes ya pueden realizar cualquier operación (subir archivos, consultar tablas, etc.) desde su instancia, siempre y cuando adjunten las políticas de IAM correctas al Role o Instance Profile que definimos en nuestro Stack inicial.

🧹 Limpieza: ¡No dejes la luz encendida!

Antes de irnos a celebrar nuestro éxito, es fundamental limpiar los recursos para mantener nuestra cuenta en $0 USD. Como mezclamos automatización con pasos manuales, el orden de eliminación es vital:

Elimina los Endpoints manualmente: Ve a la sección de Endpoints en la consola de VPC, selecciona los tres que creamos (S3, DynamoDB y EIC) y elígelos para eliminarlos. CloudFormation no puede borrar lo que él no creó.
Elimina el Security Group del EIC: Una vez borrado el endpoint, ve a Security Groups y elimina el SG-EIC-Endpoint.
Elimina el Stack de CloudFormation: Ahora sí, ve a la consola de CloudFormation, selecciona tu stack y dale a Delete. Esto borrará la EC2, la VPC y los roles automáticamente.

🏁 Conclusión

Dominar la conectividad privada es lo que separa a un administrador de nubes de un verdadero Arquitecto Cloud. Hoy demostramos que es posible construir una fortaleza segura, aislada y con un costo de red de $0, sin necesidad de NAT Gateways costosos para tareas simples.

Espero que este workshop te sirva para blindar tus arquitecturas y optimizar el presupuesto de tus proyectos.

¿Te quedó alguna duda sobre los tipos de Endpoints o la configuración de rutas? ¡Hablemos en los comentarios! 💬

Infraestructura como código con Cloudformation

Javier Madriz — Thu, 29 May 2025 21:22:20 +0000

Hola a todos! En este laboratorio práctico vamos a explorar AWS CloudFormation y descubrir cómo la infraestructura como código (IaC) puede ayudarnos a trabajar de forma más rápida, ordenada y profesional como arquitectos de soluciones.

Que es Infraestructura como codigo (Iac)?

Infraestructura como Código (IaC) es una práctica que consiste en definir y gestionar la infraestructura de TI mediante archivos de código, en lugar de realizar configuraciones manuales. Esto permite automatizar el aprovisionamiento, configuración y gestión de recursos como servidores, redes y bases de datos de forma consistente, reproducible y escalable.

Con IaC, puedes versionar tus plantillas, revisarlas como cualquier otro código y desplegar entornos completos en minutos, lo que mejora la eficiencia, reduce errores humanos y facilita el trabajo en equipo.

Ejemplo practico.

Imagina que trabajas con bases de datos RDS con frecuencia. En lugar de crear cada base de datos manualmente desde la consola de AWS lo cual puede ser lento, repetitivo y propenso a errores puedes usar una plantilla de CloudFormation para definir ese recurso con código.

Una vez que tienes esa plantilla, solo necesitas subirla y, si es necesario, modificar algunos parámetros (como la capacidad o el nombre de la base de datos). Esto te permite desplegar nuevas instancias de RDS en minutos, de forma rápida, consistente y controlada.

Sintaxis y herramienta para crear una plantilla cloudformation

Para crear una plantilla de CloudFormation puedes utilizar cualquier editor de código. En mi caso, suelo utilizar Visual Studio Code por su facilidad de uso y soporte para extensiones relacionadas con AWS.

CloudFormation permite definir las plantillas en dos formatos: JSON y YAML. A continuación te muestro un ejemplo simple en ambos formatos, para que elijas el que más te convenga o te resulte más legible.

Definamos una instancia EC2:

Sintaxis YAML

Resources:
  MiInstanciaEC2:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId: ami-06c8f2ec674c67112

Sintaxis JSON:

{
  "Resources": {
    "MiInstanciaEC2": {
      "Type": "AWS::EC2::Instance",
      "Properties": {
        "InstanceType": "t2.micro",
        "ImageId": "ami-06c8f2ec674c67112"
      }
    }
  }
}

Como puedes ver, YAML es más conciso y fácil de leer, por lo que suele ser la opción preferida de muchos desarrolladores y arquitectos al trabajar con plantillas de CloudFormation.

En mi caso, como he trabajado con Python, un lenguaje que también utiliza indentación significativa, me siento más cómodo usando YAML.

Tú puedes elegir el formato con el que te sientas más cómodo, ya que ambos son compatibles y tienen el mismo poder expresivo.

Definición de una plantilla cloudformationn

Para comenzar, necesitas crear un archivo de plantilla usando tu editor de código preferido. Puedes usar cualquiera de los dos formatos soportados por CloudFormation: YAML o JSON.

Por convención, los nombres de archivo suelen terminar en .yaml o .json, según el formato elegido.

Estructura de un template

Lo primero que debemos especificar como buena practica es la version de la plantilla, se hace de la siguiente manera.

AWSTemplateFormatVersion:

Descripción: Es un campo opcional que define la versión de la plantilla de AWS CloudFormation. Aunque puedes omitirlo, es una buena práctica incluirlo para que quede claro con qué versión del formato se está trabajando.
Formato: Usualmente se especifica en formato de fecha, como "2010-09-09".

Description:

Campo opcional que proporciona una breve descripción del propósito de la plantilla.
Posición: Puede colocarse en cualquier parte de la plantilla, aunque es habitual ponerla justo después de AWSTemplateFormatVersion (si está presente).

Estos dos segmentos la versión del formato y la descripción suelen colocarse al inicio de toda plantilla de CloudFormation, justo en la parte superior. No son obligatorios, pero es una buena práctica incluirlos para mantener claridad y orden.

Hasta el momento nuestra plantilla se ve asi:

AWSTemplateFormatVersion: "2010-09-09"
Description: This my first template

*Comencemos a definir un recurso.

Al definir un recurso en CloudFormation, es importante tener a mano la documentación oficial, ya que cada tipo de recurso tiene múltiples propiedades y no es necesario aprenderlas todas de memoria.

Tampoco necesitas usar todas las propiedades en cada caso, dependerá de lo que quieras lograr con el recurso. Usa solo lo necesario según tu objetivo.

Puedes encontrar la documentación oficial de los recursos de CloudFormation aquí:
AWS resource and property types reference

Resources:

Descripción: La sección Resources es la única obligatoria en una plantilla de CloudFormation y se utiliza para definir los recursos de infraestructura que deseas crear y gestionar con CloudFormation.
Sin la sección Resources, una plantilla de CloudFormation no sería válida, ya que no tendría recursos que crear, actualizar o eliminar.

Cada recurso se define con un identificador lógico (el nombre que tú eliges), un tipo de recurso por ejemplo, AWS::EC2::Instance para una instancia EC2 y un conjunto de propiedades que lo configuran.

Aunque esta sección suele ubicarse al final del archivo, en este laboratorio la abordamos primero porque a partir de ella aprenderemos de forma más práctica y clara cómo funcionan el resto de los segmentos de una plantilla.

Definamos una instancia EC2 en nuestro segmento de recursos, si quieres ver las distintas propiedades de una EC2 y conocer que propiedades son obligatorias u opcionales te dejo el link Definicion de una EC2, para este ejemplo usare las propiedades minimas necesarias.

Resources:
  Myinstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId: ami-06c8f2ec674c67112 # Una AMI valida para tu region

Explicación rapida:

MyInstance: es el nombre lógico del recurso dentro de la plantilla.
No es el nombre que veras en AWS, ese se puede definir con una etiqueta (Tag) si se desea.

Type: especifica el tipo de recurso que estamos creando, en este caso una instancia EC2.

Properties: aquí se definen todas las propiedades necesarias del recurso. Algunas son obligatorias (como InstanceType o ImageId para EC2), y otras dependerán del caso de uso.

Hora de desplegar nuestra primera plantilla

Hasta este punto, ya tenemos una plantilla válida y funcional que define una instancia EC2 con las propiedades mínimas. Así que estamos listos para desplegarla en AWS.

Nuestra plantilla se ve así hasta el momento:

AWSTemplateFormatVersion: "2010-09-09"
Description: This my first template

Resources:
  Myinstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId: ami-06c8f2ec674c67112 # Una AMI valida para tu region

Pasos para desplegar la plantilla desde nuestro computador usando la consola de AWS.

Ingresemos a nuestra consola y entremos al servicio de cloudformation.
Selecciona: "Crear Stack"
Selecciona: "Elegir una platilla existente"
Selecciona: "Subir un template file" y sube tu archivo.
Selecciona: Siguiente y asigna un nombre al stack
El resto de opciones dejalas por defecto y lanza el stack.

✅ Si seguiste correctamente la sintaxis (YAML) en mi caso (respetando la indentación) y escribiste las propiedades tal como indica la documentación como hicimos en el ejemplo anterior, tu stack debería haberse creado sin errores.

Al finalizar el despliegue, verás algo como esto en la consola de CloudFormation:

El estado del stack como: CREATE_COMPLETE

Una instancia EC2 creada en el servicio EC2

🎉 ¡Felicidades! Acabas de lanzar tu primer recurso en AWS usando CloudFormation.

📝 Nota importante:
En la consola de CloudFormation encontrarás muchas opciones y funcionalidades adicionales, pero ese no es nuestro enfoque en este laboratorio.

Por ahora, estamos concentrados en lo esencial: crear correctamente una plantilla y desplegar recursos.
En futuras ediciones de estos laboratorios exploraremos a fondo las capacidades de la consola y el uso de la CLI para gestionar stacks.

Que podemos mejorar?

Actualmente, la AMI y el tipo de instancia están definidos de forma estática (hardcodeados), lo que significa que siempre se usarán los mismos valores al desplegar.

Esto no es ideal si queremos reutilizar la plantilla en diferentes escenarios.
¿La solución? Usar parámetros para hacerla más flexible.

Introducción a los parámetros

Parameters:

Descripción: Aunque es opcional, esta sección es muy común y poderosa. Permite que ciertos valores de la plantilla sean definidos por el usuario al momento de desplegar, en lugar de estar codificados de forma fija.
Cuando usarlos: Cuando queremos que ciertas propiedades tengan valores dinámicos tales como: El tipo de una instancia, un AMI, el ID de una VPC etc, dichos parametros seran referenciados desde las propiedades de los recursos.

Ejemplo:

Parameters:
  InstanceTypeParameter:
    Type: String
    Default: t2.micro
    AllowedValues:
      - t2.micro
      - t2.small
    Description: "Tipo de instancia EC2 para el servidor"

Los parámetros también deben tener un nombre lógico dentro de la plantilla con el cual puedan ser referenciados desde un recurso en el ejemplo: "InstanceTypeParameter".
Tipos de parámetros: String, Number, List, AWS::EC2::KeyPair::KeyName, entre otros, para nuestro ejemplo el parámetro recibirá como valor un String.
Valor por defecto: Se puede especificar un valor por defecto para un parámetro en caso que el usuario no lo especifique.
Valores permitidos: Se pueden especificar valores como permitidos, es decir que el valor de un parámetro ingresado por el usuario debe ser uno de esa lista,si no se especifica ninguno el valor sera el especificado como default.
Descripción: Útil para especificar para que se esta usando este para parametro o a que recurso ira vinculado.

Para aprender a definir parámetros podemos repasar la documentación las veces que sean necesarias Como crear parametros

Incluyendo parámetros para nuestra plantilla

En nuestro template tenemos harcodeado el valor de la propiedad InstanceType y ImageId, así que incluyamos estos dos parámetros para que nuestra plantilla se reutilizable.

Como quedarían estos parámetros en nuestra plantilla?

AWSTemplateFormatVersion: "2010-09-09"
Description: This my first template

Parameters:
  InstanceTypeParameter:
    Description: Valor para InstanceType
    Type: String
    Default: t2.micro
    AllowedValues:
      - t2.micro
      - t2.small

  ImageIdParameter:
    Description: Valor para ImageId
    Type: String

Resources:
  Myinstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId: ami-0953476d60561c955 # Una AMI valida

Con esto ya estamos listos?
¡Aún no!

Falta un paso muy importante: referenciar los parámetros desde las propiedades como InstanceType e ImageId, para que realmente usen los valores que el usuario indique al momento del despliegue.

¿Y cómo se hace eso?

Usaremos funciones intrínsecas.

Existen muchas funciones intrínsecas que profundizaremos en ellas mas adelante por el momento nos interesa la función Ref.

Ref: La función intrínseca Ref devuelve el valor de un parámetro especificado, recurso, u otra función intrínseca. Esta función se utiliza comúnmente para crear referencias entre recursos dentro de una plantilla de CloudFormation.

Como quedaría entonces nuestra plantilla usando la función Ref para referenciar los parámetros?

AWSTemplateFormatVersion: "2010-09-09"
Description: This my first template

Parameters:
  InstanceTypeParameter:
    Description: Valor para InstanceType
    Type: String
    Default: t2.micro
    AllowedValues:
      - t2.micro
      - t2.small

  ImageIdParameter:
    Description: ID de una AMI valida
    Type: String

Resources:
  Myinstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType:
        Ref: InstanceTypeParameter
      ImageId:
        Ref: ImageIdParameter  # Una AMI valida

Como puedes ver, simplemente usamos Ref para referenciar los parámetros desde las propiedades que deben ser dinámicas y que tomaran los valores que se ingresen para cada parámetro, lo hacemos pasando su nombre lógico dentro de la plantilla a la función Ref.

Si quieres profundizar más sobre las funciones intrínsecas en CloudFormation, te dejo el enlace oficial de la documentación: Funciones Intrinseca.

Despleguemos nuestra plantilla con parámetros

Primero, eliminemos el stack anterior que usaba valores hardcodeados:

Ve a la consola de CloudFormation, selecciona el stack y haz clic en "Delete stack".

Ahora sí, subamos nuestra nueva plantilla con parámetros, siguiendo los mismos pasos que usamos anteriormente.

Selecciona: Siguiente
Asigna un nombre a tu stack
Ahora verás una sección de parámetros en la consola para asignarles un valor.
ImageIdParameter: De donde sacamos este valor?
Puedes obtenerlo desde la sección de EC2 en la consola de AWS. Abriendo una nueva pestaña, ve al Catálogo de AMIs y allí encontrarás las AMIs disponibles, las mismas que puedes seleccionar al lanzar una instancia manualmente. Solo tienes que copiar el ID de la AMI que desees usar.

En cuanto al parámetro InstanceTypeParameter, tendrá asignado un valor por defecto (t2.micro), tal como lo definimos en la plantilla. Sin embargo, también verás una lista desplegable con los valores permitidos, desde la cual puedes seleccionar otro tipo de instancia si lo deseas.

Haz clic en "Siguiente", deja los valores por defecto en las siguientes secciones y finalmente lanza tu stack.

Si todo salió bien, deberías ver tu stack con el estado "CREATE_COMPLETE". También puedes ir al panel de EC2 y revisar tu instancia: notarás que tanto la AMI como el tipo de instancia coinciden con los valores que pasaste como parámetros al momento del despliegue.

Hasta ahora hemos creado una instancia, pero no tiene asociado ningún grupo de seguridad (SG). ¿Cómo podemos crear uno y vincularlo con nuestra instancia?

Vinculación entre recursos

Primero, consultemos la documentación oficial para ver cómo definir un Security Group (SG) en CloudFormation y cuáles son sus propiedades necesarias:: Security Groups en cloudformation

Las propiedades mas relevantes son:

VpcId: Si no se especifica, el SG se crea en la VPC por defecto de la región. Puedes hardcodear el ID o, mejor aún, usar un parámetro (como ya aprendimos) y referenciarlo con Ref. Te dejo esa parte como tarea 😉.
Description: Es recomendable incluir una descripción que indique el propósito del SG o a qué recurso está asociado.
SecurityGroupIngress: Aquí defines las reglas de entrada. Puedes incluir tantas como necesites.
SecurityGroupEgress: Sirve para definir reglas de salida. En este workshop lo omitiremos, ya que por defecto se permite todo el tráfico saliente, a menos que desees restringir alguno explícitamente.

Así quedaría la definición de nuestro SG

 SecurityGroupSSH:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Permitira conexiones SSH
      VpcId:
        Ref: VpcIdParameter
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: 0.0.0.0/0

Como puedes ver, estamos permitiendo conexiones SSH al especificar el protocolo tcp y el puerto 22. Además, la propiedad VpcId no está hardcodeada, sino que hace referencia a un parámetro definido previamente, tal como te sugerí que implementaras como práctica. Esto refuerza la idea de mantener nuestras plantillas dinámicas y reutilizables.

Pero como asociamos ese grupo de seguridad con nuestra instancia?

Para esto, agregamos la propiedad SecurityGroupIds a nuestra instancia (No la habíamos agregado porque no es obligatoria a menos que quieras especificar un SG. Para asignarle el grupo de seguridad, usamos la función intrínseca Ref, tal como ya aprendimos; simplemente referenciamos el nombre lógico del grupo de seguridad creado, siguiendo el mismo proceso que antes.

Miremos nuestra plantilla completa antes de ir a desplegar:

AWSTemplateFormatVersion: "2010-09-09"
Description: This my first template

Parameters:
  InstanceTypeParameter:
    Description: Especifica el tipo de instancia
    Type: String
    Default: t2.micro
    AllowedValues:
      - t2.micro
      - t2.small

  ImageIdParameter:
    Description: Especifica una AMI
    Type: String

  VpcIdParameter:
    Description: My Vpc
    Type: String

Resources:
  Myinstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType:
        Ref: InstanceTypeParameter
      ImageId:
        Ref: ImageIdParameter  # Una AMI valida
      SecurityGroupIds:
        Ref: SecurityGroupSSH


  SecurityGroupSSH:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Permitirá conexiones SSH
      VpcId:
        Ref: VpcIdParameter
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: 0.0.0.0/0

Despleguemos nuestra nueva plantilla. Ahora, al crear el stack, ahora debes ingresar el ID de la VPC en el parámetro que añadimos.

Una vez creado el stack, ve a la consola de EC2 y revisa tu instancia; en la sección de seguridad deberías ver el grupo de seguridad asociado según lo definido en la plantilla.

Ahora que ya sabemos cómo definir y vincular recursos y parámetros, vamos a aprender cómo usar condiciones para crear plantillas más flexibles que se ajusten según el entorno o situación en que desplegamos.

Condiciones: Despliegues personalizados según escenarios

Las condiciones es una sección opcional que se crea para establecer las condiciones o circunstancias en las que se debe crear un recurso o configurar la propiedad de un recurso.

Controlar recursos según el entorno (dev o prod)

Ahora vamos a establecer que el grupo de seguridad se cree solo si el entorno es "dev", y que no se cree en producción. Para lograrlo, usaremos la sección de Conditions, que trabaja en conjunto con un parámetro (donde definimos el entorno) y algunas funciones intrínsecas de CloudFormation.

Empecemos definiendo el parámetro que ya sabemos como hacerlo.

 EnvironmentParameter:
    Description: Define el ambiente en el que se desplegaran los recursos
    Type: String
    Default: Dev
    AllowedValues:
      - Dev
      - Prod

El valor por defecto para el ambiente será Dev, pero también puedes seleccionar entre las opciones Dev y Prod al momento de desplegar la plantilla.

Ahora aprendamos a definir una condición en CloudFormation. Te dejo la documentación oficial para que puedas reforzar cualquier detalle adicional:condiciones en cloudformation

Conditions:
    EnvironmentIsDev:
      Fn::Equals: [Ref: EnvironmentParameter, Dev]

Al igual que otros elementos en nuestra plantilla, las condiciones también requieren un nombre lógico. En este caso usamos EnvironmentIsDev, ya que queremos evaluar si el entorno seleccionado es Dev.

Como mencionamos antes, las condiciones se apoyan en funciones intrínsecas. Ya conoces Ref, y ahora estamos usando una nueva: Fn::Equals, que compara dos valores. Puedes consultar la lista completa de funciones para condiciones aquí:: Funciones para condiciones

Veamos los parámetros que recibe Fn::Equals:
[Ref: EnvironmentParameter, Dev]
Aquí estamos usando Ref para obtener el valor del parámetro EnvironmentParameter, que el usuario define al momento del despliegue. Luego comparamos ese valor con la cadena "Dev".
Si coinciden, la condición devuelve true.
(Qué buenos recuerdos de Python, ¿verdad? 😄)

Ahora necesitamos vincular la condición al grupo de seguridad para que solo se cree si el entorno es Dev.
Para hacerlo, usamos la clave Condition antes de las propiedades del recurso. Así quedaría nuestro grupo de seguridad:

SecurityGroupSSH:
    Type: AWS::EC2::SecurityGroup
    Condition: EnvironmentIsDev
    Properties:
      GroupDescription: Permitira conexiones SSH a Myinstance
      VpcId:
        Ref: VpcIdParameter
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: 0.0.0.0/0

Como puedes ver, agregamos una condición a nuestro grupo de seguridad haciendo referencia directa al nombre lógico de la condición que definimos. En este caso, no es necesario usar Ref, ya que CloudFormation interpreta automáticamente el nombre de la condición.

Además, estábamos referenciando el grupo de seguridad en nuestra instancia. Si el entorno es Prod y el grupo de seguridad no se crea, AWS mostrará un error de dependencia, ya que estamos apuntando a un recurso que no existe. Para evitar esto, debemos condicionar también esa referencia, utilizando la función intrínseca Fn::If, que nos permite usar el grupo solo si la condición se cumple.

PD: Cuando usamos una condición para controlar la creación de un recurso, como hicimos con el grupo de seguridad, debemos agregar la propiedad Condition antes de las propiedades del recurso. En cambio, si la condición afecta solo una propiedad dentro de un recurso (y no su creación), usamos directamente Fn::If sin necesidad de declarar Condition al nivel del recurso. No lo olviden… ¡más adelante tendrán un reto sobre esto!

Myinstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType:
        Ref: InstanceTypeParameter
      ImageId:
        Ref: ImageIdParameter  # Una AMI valida para tu region
      SecurityGroupIds:
        - Fn::If: [EnvironmentIsDev, Ref: SecurityGroupSSH, Ref: "AWS::NoValue"]

La función Fn::If evalúa la condición EnvironmentIsDev. Si EnvironmentIsDev devuelve true, se referencia al grupo de seguridad porque este sí se creará. En caso contrario, si devuelve false, no se referencia ningún recurso ("AWS::NoValue"), lo que evita el error de dependencia por intentar usar un grupo de seguridad que no existe

Eliminemos el stack anterior para desplegar este nuevo y ver cómo funcionan las condiciones.

Revisión del stack según el entorno seleccionado

Si en el parámetro Environment elegimos Dev, nuestra instancia debería tener el grupo de seguridad creado dentro del stack correctamente adjunto.

Si al crear el stack seleccionamos Prod como entorno, el grupo de seguridad definido en la plantilla no se creará. En su lugar, la instancia tendrá asociado el grupo de seguridad por defecto de la VPC, el cual normalmente solo permite tráfico interno dentro de la misma red.

🧠 Challenge sobre condiciones

Hasta ahora, usamos condiciones para decidir si se crea o no un recurso según el valor de un parámetro (en nuestro caso: Dev o Prod).

Pero las condiciones también pueden aplicarse a propiedades dentro de recursos. ¿Te animas a hacer que la propiedad InstanceType de nuestra instancia sea t2.micro si el ambiente es Dev, y t2.small si es Prod?

🧩 Pista: Ya no necesitarás el parámetro que usábamos antes para definir el tipo de instancia 😉

Si logras completarlo, déjame un mensaje en este post diciendo "Reto cumplido Javi". Y si te atoras en algún paso, también puedes dejar tu duda en los comentarios.

Resumen

✅ Checklist: Lo que aprendiste hoy en CloudFormation

🔹 📌 Parámetros (Parameters)

Cómo crear parámetros para personalizar tu plantilla al desplegarla.

Ejemplo: elegir el tipo de ambiente (Dev o Prod).

🔹 📌 Recursos (Resources)

Cómo definir recursos como instancias EC2 y grupos de seguridad.

Cada recurso debe tener un nombre lógico, tipo y propiedades.

🔹 📌 Condiciones (Conditions)

Cómo controlar si un recurso o una propiedad se crea, usando una condición.

Declaramos condiciones con funciones como Fn::Equals.

Las condiciones pueden aplicarse a:

    Recursos completos: usando Condition antes de las propiedades.

    Propiedades puntuales: usando Fn::If dentro del valor.

🔹 📌 Funciones intrínsecas

Ref: referencia a un parámetro o recurso.

Fn::Equals: compara dos valores.

Fn::If: evalúa una condición y devuelve un valor según el resultado.

AWS::NoValue: elimina una propiedad si la condición no se cumple.

Si este workshop recibe buen apoyo e interacción en los comentarios, me animaré a llevarlo al siguiente nivel con una entrega intermedia donde abordaremos temas más avanzados como:

🔧 Checklist del próximo Workshop: CloudFormation Intermedio

🔄 📌 Actualización de Stacks con Change Sets

Qué es un Change Set y por qué es útil antes de aplicar cambios.

Cómo previsualizar el impacto de una actualización sin afectar recursos activos.

Crear y ejecutar Change Sets desde la consola o CLI.

🧠 📌 Uso de Metadata (Metadata)

Agregar información adicional a recursos (útil para herramientas, documentación o automatización).

Uso práctico con cfn-init y cfn-hup en configuraciones automatizadas.

🗺️ 📌 Mappings (Mappings)

Crear estructuras de datos tipo diccionario para condiciones según la región, ambiente, AMIs, etc.

Acceder a valores con Fn::FindInMap.

💻 📌 Despliegue de Stacks desde la Línea de Comandos (CLI)

Comandos clave de aws cloudformation para:

    Crear, actualizar y eliminar stacks.

    Validar plantillas.

    Ver eventos y salidas del stack.

Recomendaciones para automatizar despliegues y flujos de trabajo con scripts.

Hasta la próxima.

VPC y Subredes en AWS - Parte 2: Configuración de Conectividad Segura entre Recursos y hacia Internet

Javier Madriz — Thu, 07 Nov 2024 19:54:43 +0000

Bienvenidos a la segunda parte de nuestro laboratorio sobre redes y VPC en AWS! si no haz realizado la primera parte te comparto el siguiente link para que te pongas al dia workshop parte 1En esta sección, instalaremos componentes de red, lanzaremos recursos y configuraremos la comunicación tanto interna como externa hacia Internet, lo que nos llevará a construir la siguiente arquitectura

Hasta el momento, hemos creado una VPC y dos subredes: una pública y otra privada. A continuación, puedes ver su configuración en el siguiente diagrama.

Habilitar asignación de IP publica a los recursos en nuestras subredes.

En una VPC personalizada, los recursos lanzados en nuestras subredes no reciben direcciones IP públicas de forma predeterminada, a diferencia de la VPC por defecto de AWS. Para permitir que nuestros recursos se comuniquen con internet, debemos habilitar manualmente la asignación de IPs públicas, ya sea desde la configuración de subredes o al lanzar cada recurso. En este workshop, lo configuraremos directamente en la sección de subredes para la subred publica.

Ir a VPC, Subredes
Seleccionar la subred, en este caso la subred publica
En el botón de acciones seleccionar: Editar configuración de red.

Seleccionar la casilla: Habilitar la asignación automática de la dirección IPv4 pública

Recuerda que la asignación de IP también se puede habilitar al momento de lanzar cada recurso de manera independiente por si no quieres asignarle IP de manera automática a todos.

Lanzar instancia EC2 en subred publica

En este apartado no entraremos en detalles, solo te dejare los pasos ya que hemos creado instancias en otros laboratorios. Si nunca has lanzado una instancia EC2, te recomiendo revisar este post con instrucciones paso a paso: Lanzamiento de instancia EC2

Pasos:

Ir a EC2 y seleccionar "Lanzamiento de nueva instancia"
Asigna un nombre
Elige una AMI, Amazon linux estaría perfecto
Tipo de instancia: t2.micro es suficiente
Crea un par de claves SSH (Detalles en el post recomendado sobre EC2)
En configuraciones de red presiona "editar" y no olvides seleccionar la VPC creada en este laboratorio y la subred publica
En el mismo apartado crea un grupo de seguridad que permita regla de entrada SSH y HTTP. (Colócale un nombre descriptivo)
Finalmente, selecciona lanzar instancia

Podemos conectarnos a nuestra instancia?

Aunque nuestra instancia tiene una dirección IP pública, eso no garantiza la comunicación con Internet. Vamos a intentar conectarnos usando Instance Connect para comprobarlo y explicar por qué no funciona aún.

Selecciona tu instancia y dale conectar

En el siguiente apartado puedes dejar todo por defecto y darle a la opción conectar, lo que arroja el siguiente resultado:

"No se puede conectar a la instancia, asegúrese de establecer una configuración de red correcta para su instancia"

Aquí nace un nuevo concepto "Gateway de internet", necesitamos una gateway de internet para que nuestros recursos puedan acceder o ser accedidos desde internet.

Que es una Gateway de internet:

Una Internet Gateway es un componente en Amazon VPC que permite la comunicación entre los recursos en una subred pública y el Internet. Actúa como un punto de entrada y salida para el tráfico, permitiendo que las instancias con direcciones IP públicas envíen y reciban datos desde Internet. La Internet Gateway es esencial para que los recursos en la nube sean accesibles globalmente, y se utiliza en conjunto con tablas de rutas para dirigir el tráfico adecuadamente.

Creación de una Gateway de Internet.

Ir al servicio de VPC
En columna izquierda ubica la opción "Puertas de enlace de internet" o "Internet Gateways"
Veras que ya existe una, esta es la que tiene adjunta la VPC por defecto de AWS, nosotros crearemos la nuestra.
Selecciona: Crea Gateway de internet y lo único que debes hacer por el momento es asignarle un nombre yo le coloque "IGW-vpclab".
Es necesario adjuntar la IGW creada con nuestra vpc-lab creada para este workshop, simplemente la seleccionamos y en el botón de "acciones" elegimos "conectar a la VPC".

Selecciona la vpc creada en mi caso "vpc-lab" y presionas el botón conectar gateway de internet.

Con esto, ya tenemos nuestra IGW adjunta a la VPC creada para este laboratorio.

Ahora nos preguntamos: ¿pueden nuestros recursos acceder y ser accedidos desde Internet? vayamos a EC2 seleccionando nuestra instancia e intentemos conectar nuevamente:

La respuesta es no. Esto nos brinda una nueva oportunidad para explorar un componente importante en la configuración de redes: las "Tablas de enrutamiento".

Tabla de enrutamiento

Las tablas de enrutamiento en AWS controlan cómo se dirige el tráfico dentro de una VPC y hacia redes externas. Contienen reglas (rutas) que especifican a dónde enviar el tráfico según la dirección IP de destino, permitiendo, por ejemplo, la comunicación entre subredes, el acceso a Internet a través de una Internet Gateway o una conexión controlada mediante un NAT Gateway.

Con esto en mente, crearemos una tabla de enrutamiento y añadiremos una ruta que apunte a nuestra Internet Gateway para habilitar la comunicación con Internet.

Crear tabla de enrutamiento

En servicio de VPC columna izquierda seleccionamos "Tablas de enrutamiento", veras algunas predeterminadas pero crearemos nuestras propias tablas.
Seleccionar crear tabla de enrutamiento
Asigna un nombre; en este workshop, yo usare "public-route-table" ya que estará asociada a la subred pública en la que estamos trabajando.
Selecciona tu VPC que creaste para este workshop
Haz clic en "Crear tabla de enrutamiento"

Con estos pasos ya tendrás tu tabla de enrutamiento en tu VPC.

El siguiente paso es asociar la tabla que hemos creado a nuestra subred publica:

Con tu nueva tabla de enrutamiento en la VPC, selecciona la tabla y dirígete a la sección "Asociaciones de subredes" seguido de "Editar asociaciones" en la parte inferior de la pantalla.

En este apartado debes seleccionar la subred publica y darle "Guardar asociaciones".

Con esto, tu tabla de enrutamiento queda asociada a la subred pública, permitiendo el tráfico en esa subred según las reglas o rutas que se establezcan.

Creación de rutas

Las rutas en una tabla de enrutamiento son reglas que definen cómo se dirige el tráfico de red según su destino.

Por ejemplo:

La ruta con destino "local" utiliza el rango CIDR definido para nuestra VPC (en este caso, 10.0.0.0/24). Esta regla permite que el tráfico dentro del rango de IPs de la VPC se mantenga en la red interna sin salir a internet.

Por otro lado, si agregamos una ruta con destino 0.0.0.0/0 apuntando a nuestra Internet Gateway, estamos indicando que cualquier tráfico hacia una dirección externa a la VPC debe salir a internet, permitiendo que los recursos en la subred se comuniquen con redes externas.

Para agregar rutas a nuestras tablas:

Selecciona la tabla de enrutamiento. En la sección inferior, ve a la opción "rutas" y selecciona "editar rutas".

Allí verás la ruta por defecto de la que hablábamos anteriormente. Ahora, agregaremos una nueva ruta:

Usa el destino 0.0.0.0/0 y selecciona "Puerta de enlace de internet" donde te aparecerán las que tienes disponibles y debes elegir la Internet Gateway creada en este laboratorio como el recurso al cual redirigir el tráfico. Así, el tráfico hacia cualquier destino externo a la VPC podrá dirigirse a internet a través de esta gateway de internet.
Guarda los cambios y nuestra ruta será agregada.

Nota: En esta misma sección, puedes elegir redirigir el tráfico hacia otros componentes, como un NAT Gateway o una conexión VPN, según los requisitos de red que tengas.

Prueba de conexión a internet

Ya hemos configurado todos los componentes necesarios para que nuestra instancia y cualquier otro recurso en la subred pública puedan comunicarse con internet. Ahora, pongamos esto a prueba

Vayamos otra vez a EC2
Selecciona la instancia
Presiona el botón conectar dejando la configuración por defecto para usar intance connect.

Y es así como obtenemos el resultado esperado:

Es aquí donde usamos la típica frase de película: "Estamos dentro".

Además, podemos realizar un ping a un sitio como google.com para verificar que la instancia no solo es accesible desde internet, sino que también nuestros recursos pueden acceder a internet, confirmando así la conectividad.

Ahora que nuestra subred pública está configurada correctamente y sus recursos pueden comunicarse con internet, enfrentamos un nuevo desafío: entender cómo nuestros recursos en la subred privada pueden acceder a internet utilizando una NAT Gateway. También exploraremos cómo pueden comunicarse con otros recursos dentro de la misma VPC, como un host bastion. ¡Esto suena interesante!

Recursos de subred privada

Es hora de comenzar a desplegar y configurar recursos y componentes en la subred privada y comenzaremos con una instancia EC2.

Instancia EC2 en subred privada

Al igual que en el lanzamiento de la primera instancia, no profundizaremos en detalles aquí. Sin embargo, te dejo el paso a paso para crear una instancia en la subred privada y el mismo enlace a un post que explica cómo configurarla y conectarte a ella.

Lanzamiento de instancia EC2

Paso a paso:

Ir a EC2 y seleccionar "Lanzamiento de nueva instancia"
Asigna un nombre (instance-private) en mi caso.
Elige una AMI, Amazon linux estaría perfecto
Tipo de instancia: t2.micro es suficiente
Crea un par de claves SSH, un paso importante para conectarte. (Consulta el post recomendado para aprender a crear claves SSH si no estás familiarizado).
En Configuraciones de red, expande la configuración presionando "Editar" y elige la VPC creada para este laboratorio y la subred privada donde queremos que esté la instancia.
En el mismo apartado crea un grupo de seguridad que permita reglas de entrada SSH y HTTP, por el momento puede ser desde cualquier origen. (No olvides colocarle un nombre descriptivo)
Finalmente, selecciona lanzar instancia

En este punto ya tenemos nuestras dos instancias, cada una en su propia subred.

Lo siguiente que haremos será aprender cómo lograr que estas dos instancias se comuniquen entre sí de manera segura.

Comunicación entre instancias en subred publica y privada

Recordemos que para nuestra subred publica creamos una tabla de rutas, haremos lo mismo para la subred privada.
Crea la tabla y, una vez lista, asóciala a la subred privada, tal como aprendiste en los pasos anteriores. ¡Pon a prueba tus habilidades!, si no recuerdas puedes mirar como lo hicimos para la subred publica.

En este punto ya tenemos también nuestra tabla de enrutamiento para la subred privada.

Exploremos nuestra tabla adjunta a la subred privada, simplemente selecciónala y ve a la sección inferior al apartado de rutas

Hasta ahora, en la tabla de enrutamiento asociada a la subred privada solo existe una ruta predeterminada denominada "local". Esta ruta indica que cualquier tráfico cuyo destino esté dentro del rango CIDR de nuestra VPC (en este caso, 10.0.0.0/24) debe permanecer dentro de la misma VPC. Esto permite que los recursos dentro de la VPC se comuniquen entre sí sin necesidad de salir hacia internet.

Si intentas conectarte directamente a la instancia en la subred privada mediante Instance Connect o usando SSH desde tu CLI, no podrás hacerlo, ya que esta subred no tiene acceso directo desde internet. Sin embargo, puedes conectarte a la instancia en la subred pública y, desde allí, acceder a la instancia en la subred privada.

Aquí es donde entra en juego el concepto de Host Bastion.

Que es un host bastion?

Un Host Bastion es un servidor en este caso una EC2 en una subred pública que permite el acceso seguro a otras instancias en subredes privadas de la misma VPC. Como el Host Bastion tiene acceso a internet y está en la misma red que las instancias privadas, puedes conectarte primero a él y desde allí acceder a través de SSH a las instancias que hacen parte de una subred privada en la misma VPC. Esto ofrece una capa de seguridad adicional ya que evita exponer las instancias privadas directamente a internet.

Para este workshop, utilizaremos nuestra instancia en la subred pública como un Host Bastion para conectarnos a la instancia ubicada en la subred privada.

Conexión a la instancia en la subred publica

Conéctate a la instancia en la subred pública usando Instance Connect, como hemos venido haciendo. Una vez conectado a esta instancia, utilizaremos claves SSH para conectarnos a la instancia en la subred privada. Este proceso te permitirá practicar el uso de claves SSH sin necesidad de repetir el mismo procedimiento para ambas instancias.
Solo debes seleccionar la instancia publica y darle "conectar"

En el siguiente paso deja todo como predeterminado y vuelve a presionar "conectar"

Ya estando dentro de nuestra instancia en la subred pública. Ahora, desde aquí, conectémonos a la instancia en la subred privada. ¿Qué necesitamos para esto? Las claves SSH que generamos específicamente para esa instancia al momento de crearla.

Abre el archivo .pem que se descargó en tu computadora cuando creaste la clave SSH y copia su contenido.
Luego, usa el editor nano para crear un archivo en la instancia pública y pegar el contenido copiado. Esto nos permitirá tener la clave privada disponible en esta instancia.

sudo nano key-private.pem

Recuerda usar el nombre específico que le diste a tu clave.

Una vez abierto el editor en la linea de comandos, pega el contenido copiado y guarda el archivo.

Quedaria algo asi:

Recuerda que este ejemplo es con fines didácticos. Nunca compartas tu llave privada con nadie. En temas avanzados de seguridad en la nube, veremos alternativas más seguras para manejar las claves de acceso.

Para confirmar que la clave se guardó correctamente, puedes ejecutar:

cat key-private.pem

Ahora que la clave está configurada, estamos listos para conectarnos a la instancia en la subred privada desde nuestra instancia en la subred pública.

Conexión a la instancia en la subred privada

Desde la consola en el servicio de EC2 vamos a copiar la ip privada de nuestra instancia en la subred privada

Volvemos a la linea de comandos de nuestra instancia publica y ejecutamos el siguiente comando:

ssh -i key-private.pem ec2-user@10.0.0.239

Asegúrate de usar el nombre de tus llaves y la dirección ip privada de tu instancia.

Nota: Si al ejecutar el comando de conexión ves un mensaje de advertencia sobre la seguridad de la clave, es porque esta suele guardarse con permisos amplios para el usuario, grupo y otros. Sin embargo, solo el usuario necesita permisos de lectura para esta clave.

Para ajustar los permisos y resolver la advertencia, ejecuta el siguiente comando:

sudo chmod 400 key-private.pem

Este comando restringe los permisos para que solo el usuario tenga acceso de lectura. Luego, puedes ejecutar nuevamente el comando de conexión para ingresar sin problemas.

Que pasaría si intentamos hacer ping a un sitio como google.com desde la instancia privada?

No recibiremos respuestas satisfactoria ya que de momento esta instancia privada no puede comunicarse con internet pero aprenderemos como hacerlo.

Antes de continuar, es importante mencionar que hay formas más seguras de permitir el acceso. Para reforzar el concepto de bastion host, puedes configurar el grupo de seguridad de la instancia privada para que solo permita tráfico SSH desde recursos específicos. Esto puede lograrse permitiendo acceso únicamente desde un grupo de seguridad específico, una IP concreta o un rango CIDR determinado.

Revisando reglas del grupos de seguridad de la instancia privada

Si vamos al servicio EC2 y ubicamos en la columna izquierda el apartado de grupos de seguridad veremos los dos grupos que hemos para nuestras instancias en mi caso public-sg y private-sg

Exploremos el grupo de seguridad de la instancia privada

Actualmente, el grupo de seguridad permite tráfico SSH desde cualquier origen. Sin embargo, en un entorno real, solo necesitamos que un bastion host o un grupo de recursos específico tenga acceso a nuestra instancia privada. Para lograr esto, podemos establecer como origen solo los recursos que tengan asignado un grupo de seguridad específico; en nuestro caso, el grupo de seguridad de la instancia pública. Vamos a editar esta regla para reforzar la seguridad.

Seleccionar editar reglas de entrada
Elimina la regla SSH para volver a crearla
En el campo Origen, haz clic y verás diferentes opciones, como bloques CIDR, prefijos y grupos de seguridad. Selecciona el grupo de seguridad que tiene asignada la instancia pública.
Seleccionas guardar.

Ahora para la regla de entrada SSH el origen permitido seran todos los recursos que tenga el grupo de seguridad "sg-public" que en mi caso es el que tiene la instancia publica.

De esta manera, estamos limitando el acceso a la instancia privada únicamente desde el bastion host.

Ahora sí, habilitemos la comunicación de nuestra instancia privada con internet. ¿Cómo es esto posible? Aquí entra en juego un nuevo concepto: NAT Gateway.

Que es una NAT Gateway

Una NAT (Network Address Translation) Gateway es un servicio que permite a las instancias en una subred privada enviar solicitudes a internet, mientras mantiene su dirección IP privada. Al actuar como intermediaria, la NAT Gateway recibe las solicitudes de salida de la subred privada y las traduce a una IP pública. Esto permite que las instancias accedan a internet de forma segura, sin ser accesibles desde fuera de la red.

Creación de una NAT Gateway

Vamos al servicio de VPC, ubicamos NAT Gateway en la columna izquierda

Crear NAT Gateway
Asignamos un nombre, en mi caso le coloque my-nat
Debemos elegir nuestra subred publica (Indispensable)

Debemos elegir la subred pública para la NAT Gateway. Esto es indispensable, ya que una NAT Gateway necesita acceso a internet mediante la Internet Gateway de la VPC para funcionar. Así, el tráfico saliente de las instancias en la subred privada se dirige primero a la NAT Gateway, donde su dirección IP privada se traduce a una IP pública para acceder a internet. Al recibir la respuesta, la NAT Gateway invierte el proceso, reemplazando la IP pública con la IP privada original antes de enviar el tráfico de regreso a la subred privada.

Asigna una dirección IP elástica, simplemente pulsando el botón que dice "Asignar IP elástica"

Pero que es una dirección IP elástica y porque es necesaria?

Una dirección IP elástica (Elastic IP o EIP) es una dirección IP pública y estática que AWS asigna a una cuenta, y que puedes reasignar entre distintas instancias o recursos dentro de una región. A diferencia de una dirección IP pública común, que puede cambiar si detienes y reinicias una instancia, una EIP permanece constante hasta que tú decidas liberarla.

Para una NAT Gateway, una EIP es esencial porque garantiza que las solicitudes salientes desde la subred privada mantengan una IP pública fija, facilitando la comunicación con servicios externos y permitiendo que las respuestas regresen correctamente a la NAT Gateway.

Por ultimo selecciona "Crear gateway NAT"

Ahora, vamos a la tabla de enrutamiento de la subred privada y creamos una ruta hacia la NAT Gateway

Agregamos una ruta para que el tráfico destinado a cualquier dirección (0.0.0.0/0) desde nuestra subred privada se dirija a la NAT Gateway. Simplemente seleccionamos la opción "Puerta de enlace NAT" y aparecerá la NAT que creamos.
Finalmente, presiona "Guardar cambios".

Con la ruta configurada hacia la NAT Gateway, ahora podemos hacer un ping a google.com desde nuestra instancia en la subred privada para verificar que la conectividad a Internet está funcionando correctamente.

Ahora si estamos recibiendo respuesta a nuestras solicitudes hacia internet.

Algunas aclaraciones:

Ruta implícita de la NAT Gateway: La NAT Gateway ya tiene una ruta implícita hacia la Internet Gateway, por lo que no es necesario crear una ruta adicional desde la NAT hacia la Internet Gateway.

Restricción del tráfico de entrada: El tráfico de entrada no puede llegar directamente desde Internet hacia la NAT Gateway. Esta solo maneja respuestas a solicitudes salientes, asegurando que solo el tráfico iniciado desde la subred privada pueda recibir respuestas.

Si vemos un diagrama mas detallado seria algo asi:

Resumen

Espero que hayan aprendido mucho sobre estos conceptos. Aunque algunos temas se desvían del objetivo principal, el propósito es que comprendan el "porqué" de cada acción y no pasen por alto conceptos importantes.

Creamos una Internet Gateway.
Configuramos tablas de enrutamiento y agregamos rutas.
Establecimos un Host Bastion.
Conectamos nuestras instancias mediante SSH.
Establecimos comunicación entre nuestros recursos
Configuramos una NAT Gateway con una IP elástica.
Realizamos peticiones a Internet desde nuestra instancia privada y recibimos respuestas satisfactorias.
Profundizamos en conceptos clave relacionados con redes y seguridad

Espero que les haya gustado. Como siempre, les invito a interactuar con el contenido, compartirlo y comentarme si aprendieron algo nuevo o si tienen alguna duda.

Fundamentos de Redes en AWS: VPC y Subredes - Parte 1

Javier Madriz — Wed, 30 Oct 2024 20:03:41 +0000

Hola a todos, gracias por leer este post. En esta guía, aprenderemos todo sobre las VPC (Virtual Private Cloud) y sus componentes. La guía estará dividida en dos publicaciones: en esta primera, crearemos la VPC y las subredes pública y privada, explicando los conceptos fundamentales. En el segundo post, añadiremos componentes clave para gestionar la comunicación entre recursos dentro de la VPC y el acceso hacia y desde internet.

Al terminar esta primera fase tendremos esta arquitectura

Que es una VPC?

Una VPC (Virtual Private Cloud) es una red privada virtual en AWS que nos permite desplegar y gestionar nuestros recursos en un entorno seguro y aislado dentro de la nube de AWS. En una VPC, tenemos control total sobre la configuración de red.

Vamos a construir la primera parte de este workshop paso a paso, profundizando en los conceptos más relevantes. Para comenzar, accedamos a la consola de AWS.

Al ingresar al servicio de VPC, notaremos que ya existe una VPC creada por defecto, proporcionada por AWS para facilitarnos el inicio en el despliegue de nuestros recursos.

Selecciona crear VPC
Verás dos opciones: "Solo la VPC" y "VPC y más". La primera crea únicamente la VPC, mientras que la segunda incluye componentes adicionales, como subredes. Para profundizar en los fundamentos, seleccionaremos "Solo la VPC".
Asigna un nombre a tu VPC, yo la llamare "vpc-lab"
El siguiente paso es crear un CIDR, explicaremos brevemente que es esto y para que sirve.

¿Qué es un CIDR y para qué sirve?

El CIDR (Classless Inter-Domain Routing) es un método para asignar rangos de direcciones IP que se utilizan en la configuración de una VPC. Al establecer un CIDR, definimos un rango de direcciones IP disponibles para asignar a nuestros recursos, como instancias EC2 y bases de datos.

También es importante considerar el tamaño del rango, que se especifica con notación CIDR. Por ejemplo, un /16 permite hasta 65.536 direcciones IP, mientras que un /28 permite solo 16. Para la mayoría de los entornos, un /24 (256 direcciones) es un buen punto de partida.

Si deseas comprobar cuántas direcciones puedes asignar con un CIDR según el prefijo que utilices, puedes visitar esta herramienta que calcula la cantidad de IP disponibles en un CIDR: CIDR

¿Qué es una dirección IP?

Las direcciones IP son identificadores únicos para dispositivos en una red y se dividen en dos categorías: públicas y privadas. Existen dos versiones de direcciones IP: IPv4 e IPv6. Para este taller, nos centraremos en IPv4, que es la versión más comúnmente utilizada en redes y en la configuración de nuestra VPC.

Direcciones IP Públicas:

Son únicas a nivel global y se utilizan en Internet para identificar dispositivos y servicios en todo el mundo. Cada dirección IP pública es exclusiva y no se repite en ninguna otra red en Internet.

Direcciones IP Privadas:
No se pueden comunicar con Internet por sí solas: Las direcciones IPv4 privadas se utilizan en redes locales, como redes domésticas o empresariales, pero no son accesibles directamente desde Internet. Sin embargo, se pueden utilizar en combinación con la traducción de direcciones de red (NAT) para permitir que los dispositivos en una red privada accedan a Internet a través de una dirección IP pública compartida.

Entendido esto, podemos seguir.

Asignemos nuestro CIDR Para este laboratorio, utilizaremos el rango 10.0.0.0/24, que nos proporciona 256 direcciones IP. Es importante mencionar que AWS reserva las primeras cuatro direcciones y la última de este rango para uso interno, según la ultima información que he leído. Si te interesa, puedes investigar más sobre este tema.

Asignas una etiqueta (Opcional) y seleccionas "Crear VPC"

Mientras la VPC se crea, quiza te estas preguntando como se calcula la cantidad de IPs en un CIDR.

Como se calcula la cantidad de direcciones IP en un CIDR?

Una dirección IPv4 está compuesta por 32 bits, distribuidos en 4 secciones de 8 bits cada una, llamadas octetos. El bloque CIDR se representa como una dirección IP seguida de una barra diagonal y un número (por ejemplo, 10.0.0.0/24). El número después de la barra, conocido como prefijo, indica cuántos bits de esos 32 se utilizan para la parte de red.

Para calcular la cantidad total de direcciones IP en un bloque CIDR, utilizamos la siguiente fórmula:

Números de direcciones IP = 2^(32-prefijo)

32 es el número total de bits en una dirección IPv4.
Prefijo es el número que sigue a la barra (en 10.0.0.0/24, el prefijo es 24).

Ejemplo: Para un bloque CIDR de 10.0.0.0/24:

Numero de direcciones IP = 2^(32-24) = 2^8 = 256

Explicado esto, ya podemos continuar, la idea es que entiendas conceptos que son fundamentales.

Seguimos:

Si vamos nuevamente a la opción "Sus VPC" podremos ver que tenemos la VPC por default y la que acabamos de crear, si no aparece con nombre asignado se lo puedes asignar, podrás identificarla por el CIDR que usamos.

Redes y Subredes

¿Qué son las subredes y para qué sirven?

Una red puede estar compuesta por varias subredes, cada una con un número asignado de direcciones IP del rango definido en la red principal. Estas direcciones se utilizan para ser asignadas a recursos en cada subred. Existen subredes públicas y privadas:

Subred pública: Tiene acceso a Internet a través de una puerta de enlace de Internet (Internet Gateway) por lo cual en ella se suelen desplegar recursos que pueden o deben estar expuestos a internet.

Subred privada: No es accesible desde Internet, pero puede conectarse a él mediante una NAT Gateway, lo que significa que no puede ser accedida directamente desde Internet.

Los componentes mencionados se explicarán cuando los estemos creando.

¿Cuándo necesitamos subredes públicas o privadas?

Usamos subredes públicas para recursos que necesitan ser accesibles desde y hacia Internet, como una aplicación web. Por otro lado, las subredes privadas albergan recursos que no deben estar expuestos, como bases de datos.

Creación de subredes

En la sección izquierda del servicio VPC, selecciona "Subredes" podras ver las subredes asociadas a la VPC por defecto de AWS. A continuación, crearemos nuestras propias subredes.
Haz clic en "Crear Subred".
Selecciona la VPC que has creado, en mi caso la llame "vpc-lab".
Asigna un nombre a la subred; yo la nombraré "subred-publica".
Zona de disponibilidad elige la 1A de la región en la que te encuentres, yo estoy trabajando en la región de norte de virginia así que seleccionare us-east-1a

Observaras el bloque CIDR de tu VPC, que es 10.0.0.0/24, lo que proporciona 256 IPs.

Como vamos crear dos subredes, dividimos el rango de IPs de nuestra VPC en nuestras dos subredes. Asignaremos un CIDR a cada subred lo que facilitara la comprensión de su funcionamiento y podras notar como a cada una se le asigna la mitad de Ids disponibles.
A esta subred pública le asignaremos el CIDR 10.0.0.0/25, lo que le proporciona 128 IPs en el rango de 10.0.0.0 a 10.0.0.127.

Teniendo ya esta configuración puedes seleccionar "Crear subred"

Crearemos la subred privada siguiendo los mismos pasos anteriores, cambiando solo el nombre, eligiendo la zona 1b y asignando el CIDR.

Asigna el CIDR 10.0.0.128/25 a la "subred-privada", lo que le proporciona las 128 IPs restantes en el rango 10.0.0.128 a 10.0.0.255.

Teniendo ya esta configuración puedes seleccionar "Crear subred"

Si revisamos la información de nuestras subredes veremos lo siguiente:

Verás que en la sección de IPs disponibles para cada subred se muestran 123, en lugar de las 128 asignadas. Esto se debe a que AWS reserva 5 direcciones IP en cada subred (las cuatro primeras y la última). Es importante tener esto en cuenta al diseñar tus redes.

Resumen

Creamos una VPC.
Configuramos subredes públicas y privadas.
Repasamos conceptos clave: VPC, CIDR, direcciones IP y subredes.

En el siguiente post, abordaremos:

Creación de una Internet Gateway.
Configuración de una NAT Gateway.
Despliegue de recursos en nuestras subredes.
Gestión de la comunicación entre los recursos de la subred pública e Internet, y cómo los recursos de la subred privada se conectan al exterior sin ser accesibles desde Internet.

Obteniendo la siguiente arquitectura:

Hasta la próxima entrega.

No olvides interactuar con el contenido y compartirlo

Análisis Exploratorio de datos (EDA) con Apache Spark

Javier Madriz — Wed, 25 Sep 2024 13:29:44 +0000

Que es un analisis exploratorio de datos y por que es importante?

El análisis exploratorio de datos (EDA) nos ayuda a entender la estructura de los datos, identificar anomalías y detectar posibles transformaciones necesarias para un procesamiento adecuado. Desde la perspectiva de un ingeniero de datos, el EDA es clave para planificar las correcciones y optimizaciones que se implementarán más adelante en un pipeline ETL.

En este post, nos enfocaremos en detectar anomalías en los datos, dejando el análisis estadístico y la búsqueda de correlaciones para los analistas. Identificaremos las correcciones necesarias y explicaremos su importancia, para luego implementarlas en un pipeline de datos con AWS Glue y Apache Spark en un post posterior. ¡Será una serie completa e interesante!

Conjunto de datos

El conjunto de datos que vamos a utilizar para este ejercicio contiene datos sobres las 100 corporaciones con una cultura apegada a la sostenibilidad y amigables con el medio ambiente, el cual lo pueden conseguir en Kaggle: Descarga aqui el conjunto de datos

El entorno para hacer la exploración de los datos puede ser cualquier de tu preferencia, yo lo hare en un notebook de Glue.

Lo principal es leer los datos, te mostrare como se leen desde glue, no te preocupes si no entiendes el código, posteriormente hare una serie de glue donde lo aprenderás a profundidad, ahora el interés esta puesto en como y porque explorar la data.

dyf = glueContext.create_dynamic_frame.from_catalog(
    database = "greencompany",
    table_name = "greencompanies",
    transformation_ctx = "greencompaniessource",
    format_options = {"withHeader": True}
)

Análisis del Esquema de los Datos: Para comprender mejor nuestro dataset, comenzamos por examinar su esquema. Esto nos permite identificar las columnas que lo componen y sus respectivos tipos de datos, lo que es crucial para garantizar la calidad de los datos y la precisión en los análisis posteriores.

Como se hace esto en spark?

dyf.printSchema()

Que podemos observar?

Columna Previous Rank: Actualmente, esta columna tiene un tipo de dato String, es recomendable cambiar al tipo de dato Integer. Esta conversión permitirá realizar comparaciones y cálculos de manera más eficiente, mejorando la calidad de los análisis posteriores.

Columnas que en sus nombres contienen (%): El uso del símbolo de porcentaje en los nombres de las columnas puede dificultar el análisis y el filtrado de datos. Es recomendable evitar este tipo de símbolos en los nombres, ya que existen otras formas de indicar la referencia de cada columna sin complicar su uso. Optar por nombres más descriptivos y sin caracteres especiales facilitará el análisis de datos y mejorará la claridad en la interpretación de los resultados.

Columnas que almacenan datos numéricos: Las columnas que almacenan datos numéricos (Revenue, Profit, CEO Pay Ratio, Women on Board, Women in Leadership y Women in Workforce) deben tener su tipo de datos cambiado a integer o float, según corresponda. Esto permitirá aprovechar al máximo su uso en análisis y cálculos.

Una simple inspección al esquema nos dejo ver múltiples transformaciones necesarias, sigamos explorando.

Ahora miremos algunas registros de nuestros datos para a ver que mas conseguimos:

Convertimos nuestro dynamic frame que es lo que usa glue a un dataframe de pyspark para usar una sintaxis con la que estamos mas relacionados.

df = dyf.toDF()
df.show(3)

Podremos observar todas las columnas y solo 3 registros, me centrare en la columna "Location"

Columna Location: Contiene tanto la ciudad como el país. Sería útil crear columnas separadas para ciudad y país, lo que proporcionaría información más granular para los analistas.

Tamaño de nuestros datos: Es fundamental conocer el tamaño de nuestros datos para implementar buenas prácticas de rendimiento, como ajustar el número de workers, particiones o definir la persistencia de los datos. A diferencia de Pandas, donde usamos df.shape, en Spark no hay una función nativa para esto, pero podemos obtener la cantidad de filas usando df.count() y el número de columnas con len(df.columns). Esto nos permitirá conocer el tamaño de nuestros datos para planificar mejor la ejecución y optimización de los trabajos.

row = df.count()
columnas = len(df.columns)
print((row, columnas))

Columnas categóricas: Al trabajar con columnas categóricas como "Climate Grade", es esencial verificar la consistencia de los valores. Usar distinct() ayuda a identificar las categorías únicas y detectar posibles duplicados que podrían no ser evidentes, como diferencias causadas por espacios, símbolos o variaciones en la escritura. Esto asegura la calidad de los datos, evitando problemas en el análisis o modelado. Un ejemplo común es una columna de género que puede contener registros como "F", "M" y "Female", donde "F" y "Female" deberían ser tratados como la misma categoría.

df.select('Climate Grade').distinct().show()

Conteo de nulos por columna: Identificar valores nulos es crucial para asegurar la calidad del análisis de datos. Tener un claro entendimiento de en qué columnas se encuentran y en qué cantidad permite tomar decisiones informadas sobre cómo tratarlos. En Pandas, esto se logra fácilmente con df.isnull().sum(), pero en Spark, el proceso es un poco más complejo debido a la naturaleza distribuida de los datos, como siempre hay muchas formas de hacer las cosas yo suelo hacerlo de la siguiente manera:

null_per_columns = df.select([sum(col(c).isNull().cast('int')).alias(c) for c in df.columns])
null_per_columns.show()

Consistencia de datos: Al analizar las variables categóricas, verificamos si hay repeticiones inesperadas. Sin embargo, no siempre la solución es tan directa, y en ocasiones debemos considerar la consistencia de los datos. Por ejemplo, en nuestro dataset, la columna "Company" podría sugerir que ninguna compañía debería repetirse, ya que estamos trabajando con datos sobre empresas eco-friendly organizadas en una especie de ranking. Sin embargo, la columna "Industry" introduce una excepción importante: ¿qué pasa si una misma compañía opera en varias industrias? En ese caso, sería válido que una compañía aparezca varias veces en el dataset, pero diferenciada por la industria en la que opera, como suele suceder con las filiales de grandes empresas. Para verificar esto, podemos agrupar por Company y contar cuántas industrias únicas tiene cada una.

El siguiente código agrupa las compañías y calcula cuántas industrias distintas están asociadas a cada una:

inconsistencia = df.groupBy('Company').agg(countDistinct('Industry').alias('industrias_unicas'))
inconsistencia.show(10)

Hasta ahora, hemos conocido varios aspectos clave del análisis exploratorio de datos y el propósito que buscamos con esta práctica. Resumiendo las transformaciones necesarias para nuestros datos, encontramos los siguientes puntos:

Convertir la columna "Previous Rank" de string a integer.
Corregir los nombres de columnas que necesitan incluir el símbolo (%).
Columnas que almacenan datos de capital, ganancias, proporciones etc, corregir cambiando el tipo de datos de string a float o integer.
La columna "Location" contiene la ciudad y país, se debe separar la columna "Location" en dos columnas independientes: una para ciudad y otra para país.
Manejo de nulos, bien sea reemplazándolos por un valor estadístico o simplemente eliminándolos si no generan ningún impacto significativo.

Estas transformaciones las implementaremos en un pipeline de datos en AWS, utilizando Glue, Crawlers, el Catálogo de Datos, S3, y Athena para realizar consultas y asegurarnos de que nuestros datos estén limpios. Esta será la primera entrega de una serie de tutoriales sobre AWS Glue, donde explicaremos cada uno de los componentes, cual es su proposito, como debemos integrarlos en nuestro pipeline y en que escenarios se debe usar unos u otros.

Como siempre les digo, si tienen alguna opinión, duda no dejen de interactuar con el contenido.

Hasta la proxima.

Implementando Escalabilidad, Alta Disponibilidad y Monitorización en una Arquitectura de AWS

Javier Madriz — Thu, 08 Aug 2024 19:15:06 +0000

Introducción

El objetivo de este ejercicio técnico es diseñar e implementar una arquitectura en AWS para un portal web, con requisitos de alta disponibilidad, tolerancia a fallos y monitoreo eficiente. Utilizaremos servicios como ASG, EC2, ALB. S3, CloudWatch y SNS.

Descripción General

Podemos ver los componentes principales organizados en diferentes capas, desde la capa de la nube de AWS, pasando por la región y la VPC. Un grupo de auto escalado será el encargado de lanzar o disminuir instancias que consumirán contenido estático desde S3. Por otro lado, el balanceador de carga redistribuirá las peticiones de los usuarios entre las instancias disponibles en nuestro ASG. Cuando una nueva instancia sea lanzada, el ASG enviará una notificación a un tema de SNS y los suscriptores de ese tema recibirán un correo electrónico. CloudWatch monitoreará nuestra arquitectura y activará una alarma cuando una instancia sea terminada, enviando una notificación a un tema de SNS para que los suscriptores reciban una notificación por correo electrónico. Además de monitorear métricas para alarmas independientes, también es parte de la implementación de políticas de auto escalado.

Comenzaremos creando las cosas más básicas pero indispensables para nuestra arquitectura:

Crear un Bucket de S3, asigna un nombre descriptivo, habilita el versionado y mantenlo como privado, el resto de las opciones déjalas como predeterminadas, una vez creado el bucket carga un archivo html con el nombre index.html que se mostrara en tu aplicación, puedes descargar mi index.html desde el siguiente repositorio GitHub
Rol de servicio EC2: Este rol contendrá políticas de acceso a S3 y CloudWatch, estas políticas permitirán que nuestras instancias copien el archivo index.html desde S3 y que nuestras instancias envíen métricas e interactúen con CloudWatch para crear o modificar alarmas asi como el envio de logs entre otras funcionalidades, vayamos al servicio de IAM para crear el rol.

Crear Rol
Rol de servicio
Casos de uso: EC2
En politicas asignaremos las ya mencionadas:

Grupos de seguridad: Debemos crear 2 grupos de seguridad uno para nuestras instancias y el segundo para nuestro balanceador de carga los cuales permitiran o no el trafico entrante de acuerdo a las reglas de trafico de entrada que asignemos.

Vamos al servicio EC2, en la columna izquierda, "security groups" y creamos el primer grupo para la nuestra web en mi caso le di el nombre de SG-Web-App-Madriz y contiene las siguientes reglas de entrada

El segundo grupo de seguridad es para nuestro ALB yo lo llame "SG-alb-web-madriz" y solo permite trafico http.

Balanceador de carga

Un balanceador de carga ALB (Application Load Balancer) en AWS distribuye automáticamente el tráfico entrante entre múltiples instancias de EC2 en nuestro caso, en diferentes zonas de disponibilidad, optimizando la disponibilidad y la capacidad de respuesta de la aplicación.

Este recurso también se crea desde la sección de EC2, columna izquierda y sección "Balanceadores de carga"

Crear balanceador de carga de tipo ALB
Asignamos un nombre en mi caso "alb-asg-web-madriz"
En esquema: El ALB debe estar expuesto a internet, "Internet facing"
Tipo de dirección: IPv4
Mapeo: Seleccionaremos las tres zonas de disponibilidad que aparecen. Un balanceador de carga debe ser capaz de enviar tráfico al menos a dos zonas de disponibilidad, asignando una subred por zona. Esto asegura que nuestra arquitectura sea tolerante a fallos y altamente disponible, ya que, si una zona de disponibilidad falla, el tráfico se redirigirá automáticamente a las instancias en las otras zonas.

En la seccion del grupo de seguridad seleccionamos el grupo de seguridad creado para el ALB en la primera seccion de este laboratorio, en mi caso lo nombre "SG-alb-web-madriz"
Agentes de Escucha y Direccionamiento
Agentes de Escucha: Los agentes de escucha están configurados con el puerto en el que el ALB (Application Load Balancer) escuchará las solicitudes entrantes, como el puerto 80 para HTTP y el puerto 443 para HTTPS.

Grupos de Destino: Son contenedores de instancias donde el balanceador de carga dirigirá el tráfico, considerando la salud de cada instancia, su capacidad y la estrategia de balanceo de carga.

Nuestra arquitectura utilizará un grupo de autoescalado (ASG) que lanzará o terminará instancias según la demanda de nuestra aplicación. Debemos crear este grupo de destino vacío. Al configurar el ASG, gestionaremos cómo cada instancia lanzada se agregará automáticamente a este grupo de destino.

Al crear el grupo de destino debemos especificar lo siguiente:

El tipo de grupo de destino es de: Instancias
Asigna un nombre al grupo de destino
Elija un puerto y protocolo para nuestro grupo destino en este caso eligiremos puerto 80 para HTTP.
Lo demas queda como preterminado (IPv4, vpc default, version de protocolo, protocolo de comprobacion de estado HTTP)

Nota: Cuando eliges el protocolo y puerto en el grupo de destino, estás definiendo el protocolo y puerto en el que cada instancia en el grupo estará escuchando el tráfico reenviado por el ALB

El siguiente paso es registrar instancias dentro del grupo destino, pero como nuestras instancias seran levantadas por ASG no debemos especificar ninguna, solo crear el grupo vacio, en el caso que nuestra app no tenga auto escalado y tenga un numero especifico de instancia creadas por nosotros si debemos incluirlas en este grupo.
Una vez creado el grupo de destino ahora si podemos elegirlo en la lista desplegable en el apartado de agentes de escucha y direccionamiento.

Para finalizar revisaremos el resumen y crearemos nuestro ALB, así que, damos por terminada esta sección de ALB.

Creando ASG

Ir al apartado de EC2 en la consola de AWS
En la columna izquierda al final ubicar "Auto scaling"
Creemos un grupo de auto scaling

Debemos asignar un nombre a nuestro grupo de auto escalado y elegir una plantilla de lanzamiento, si te estas preguntando "con que se come eso", no te preocupes ya te lo explico.

Platilla de lanzamiento

Una plantilla de lanzamiento es un conjunto de configuraciones iniciales que tendrá cada instancia que nuestro grupo de autoescalado (ASG) inicie. Se llama plantilla porque es una configuración única que el ASG usará para todas las instancias que lance, asegurando que, independientemente de la instancia a la que el usuario sea dirigido por el balanceador de carga (ALB), verá la misma aplicación. Esto garantiza la consistencia y uniformidad en todas las instancias del ASG.

Asignar nombre al ASG y luego seleccionamos crear plantilla de lanzamiento, si no tienes ninguna.
Asignamos un nombre a nuestra plantilla y descripción

Las siguientes configuraciones son las mismas que utilizamos cuando creamos una instancia EC2, con un ligero cambio en la sección de configuración avanzada. Si nunca has creado una instancia EC2, te dejo un laboratorio donde explico los detalles paso a paso. Como crear una instancia EC2 y conectarme con SSH

Seleccionamos inicio rapido y elegimos la AMI de amazon linux
Tipo de instancia t2.micro es suficiente para el proposito de este taller.
El siguiente paso es crear un par de claves de seguridad, recuerda que esto nos ayudara a establecer conexion desde nuestro computador a nuestras instancias.
En grupos de seguriad elegiremos el grupo creado en la primera seccion, recuerda que creamos uno para el ASG y otro para el ALB, en mi caso le di el nombre "SG-Web-App-Madriz" la unica diferencia que tiene uno del otro es que este grupo de seguridad permite trafico HTTP y SSH mientras que el grupo del ALB solo permite trafico HTTP.

Nota: Ya en otros talleres hemos creado instancias, llaves seguras, grupos de seguridad, por eso no estoy profundizando en estas caracteristicas basicas.

Nos desplazaremos hasta la seccion de configuraciones avanzadas, atencion aqui:

El primer parametro es el Perfil de la instancia: Un perfil de instancia en AWS es una entidad que permite a las instancias EC2 obtener permisos para interactuar con otros servicios de AWS mediante la asociación de un rol de IAM
Elegiremos el rol que creamos al inicio de este laboratorio que ya contiene las politicas necesarias que necesitan nuestras instancias.

Iremos hasta la seccion User-Data: El apartado user-data en AWS permite especificar scripts o comandos que se ejecutan automáticamente al iniciar una instancia EC2, utilizado comúnmente para configuraciones iniciales o instalación de software.

A continuacion te dejo el codigo a implementar en este apartado, solo debes reemplazar el nombre del bucket con el nombre que hayas usado.

#!/bin/bash

# Actualizando el sistema
yum update -y

# Instalando apache
yum install -y httpd

# Iniciando apache
systemctl start httpd

# Habilitar Apache para que se inicie automáticamente al arrancar el sistema
systemctl enable httpd

# Instalar AWS CLI
yum install -y aws-cli

# Mueve el archivo HTML desde el bucket S3 a la instancia, coloca el nombre de tu bucket
aws s3 cp s3://your-bucket/index.html /var/www/html/index.html

# Reiniciar Apache para aplicar los cambios
systemctl restart httpd

También puedes encontrar este archivo en el Repositorio GitHub, solo debes pegar este código o adjuntar el archivo en el recuadro user-data

En este punto ya tienes todo para crear tu plantilla de lanzamiento y ahora puede ser elegida para que a partir de dicha plantilla podamos crear nuestro grupo de auto escalado.

Hacemos clic en 'Siguiente' y accedemos a las configuraciones de red. Elegiremos la VPC por defecto que estamos usando y seleccionaremos las tres zonas de disponibilidad disponibles en la lista desplegable. Esto asegura que nuestro ASG cubra dichas zonas y pueda lanzar instancias EC2 en cada una de ellas, garantizando así alta disponibilidad
En el siguiente paso es hora de elegir nuestro balanceador de carga y grupo destino creado anteriormente asi que elegimos la opcion "Asociar balanceador de carga existente" pueden notar que en la lista desplegable aparece el nombre del grupo y a que balanceador de carga pertenece.
Nos desplazamos hasta las comprobaciones de estado y elegimos "Activar las comprobaciones de estado de Elastic Load Balancing" esto hace que nuestro ALB compruebe el estado de nuestras instancias antes de enviarle trafico, cuando el ALB informe sobre una instancia en mal estado el grupo ASG reemplazara dicha instancia.
Habilitamos también la recopilación de métricas del ASG para que sean enviadas a CloudWatch y hacer uso de alarmas basadas en métricas, click en siguiente.
Capacidad Deseada: La definiremos en 2. En condiciones normales, nuestra aplicación tendrá 2 instancias activas en el grupo ASG. Si una instancia se termina por error o cualquier otro motivo, una nueva instancia será lanzada para mantener la capacidad deseada de 2.
Capacidad Mínima: La definiremos en 1. Nuestro ASG puede escalar hacia abajo hasta un mínimo de 1 instancia. Dado que la capacidad deseada es 2, el ASG solo escalará a 1 si una política de escalado lo indica, en función de la demanda.
Capacidad Máxima: La definiremos en 3. Si implementamos una política de autoescalado que observe la alta demanda de la aplicación, el ASG escalará como máximo a 3 instancias.

Esto asegura que nuestra arquitectura sea flexible y pueda adaptarse a diferentes niveles de demanda, manteniendo siempre un rendimiento óptimo.

Añadir notificación: Dentro de la configuración de nuestro ASG podemos activar notificaciones de SNS para que usuarios suscritos a un tema reciban un mensaje cuando el ASG lance o termine instancias.
Si no tienes un tema debes crear uno, especifica el nombre del tema, los correos electrónicos de los suscriptores que recibirán la notificación.
Puedes activar todos los eventos, pero para este laboratorio activaremos solo el evento de lanzamiento de una nueva instancia, el evento de cuando una instancia se termine lo haremos con CloudWatch más adelante.

Es hora de revisar todos los parámetros establecidos en nuestro ASG, si todo está en orden procedemos a crear el grupo de auto escalado.

Inmediatamente el ASG levantara las instancias deseadas con la configuración especificadas en el user-data que además de instalar y poner en marcha apache, acceder al bucket S3 y copiar el archivo index.html

Revisando funcionamiento:

Vayamos a la consola de EC2 y entremos a la sección de balanceadores de carga, seleccionemos nuestro balanceador de carga y en la pestaña detalles copiemos el nombre de DNS.

Pegamos el nombre de DNS en el navegador y veremos nuestra App.

Revisando Instancias

Vayamos al apartado de instancias para verificar que la cantidad de instancias desplegadas cumple con lo especificado en nuestro ASG al momento de crearlo.

Podemos observar que el numero de instancias desplegadas es 2, esto cumple con lo establecido en la capacidad deseada de nuestro ASG.

Antes de realizar pruebas de escalado, agreguemos monitorizacion a nuestra arquitectura.

Monitoreo con CloudWatch

Las alarmas de cloudWatch pueden ser creadas de manera individual utilizando métricas de instancia o ASG, una vez estas métricas alcancen ciertos umbrales dichas alarmas harán alguna acción bien sea enviar un mensaje SNS o activar una política de escalado, en nuestro caso queremos que una alarma se active cuando una instancia sea terminada y nos envié un mensaje por correo electrónico.

Dirígete a CloudWatch hasta el apartado de alarma
Crear una alarma y elegir métrica: En este punto queremos medir una métrica que es enviada desde el grupo ASG a CloudWatch.
Seleccionar Auto Scaling como el servicio de donde se obtendrá la métrica
Métricas de grupo: En este punto veras una lista de métricas que puedes seleccionar para crear una alarma para este laboratorio usaremos la métrica "GroupTerminatingInstances"

Seleccionar métrica y pasar al siguiente apartado
Veras el nombre la métrica
El grupo ASG del cual proviene la métrica
Elige la estadística que quieres medir, para este laboratorio usaremos la media.
El periodo será de 5 minutos
La condición será que cuando en un periodo de 5 minutos la media de instancias terminadas en nuestro ASG sea mayor o igual a 1 una alarma sea activada.

Que haremos con la alarma?

Cuando nuestra arquitectura este en modo alarma enviara una notificación SNS a los suscriptores de un tema, podemos elegir el mismo que creamos en el ASG.

Establece un nombre a la alarma y opcionalmente un mensaje personalizado, en mi caso dejare el prederminado.

Ahora si podemos hacer pruebas de escalado:

Apaga una de las instancias y una alarma de CloudWatch se activara y un correo electronico recibiras alertandote.

Instancia terminada:

Modo alarma activada porque se cumplio la condicion especificada:

Una notificacion se envio al correo electronico del suscriptor especificado en el tema SNS.

Adicionalmente podemos chequear que nuestro ASG cumpliendo con la capacidad deseada de 2 instancias ya levanto una nueva instancia.

Notificacion SNS por lanzamiento de una nueva instancia:

Con esto hemos puesto a prueba nuestra arquitectura, nuestra App funciona, cuando terminamos una instancia el ALB lo detecta y dirige el tráfico a las únicas instancias saludables es por eso que al terminar una instancia si refrescamos el navegador nuestra App seguirá disponible sin mostrar error para la instancia que está terminada, por otro lado cuando la instancia está terminada una alarma de CloudWatch se activa y envía una notificación de SNS, además nuestro ASG en cumplimiento con la capacidad deseada lanza una nueva instancia y envía una notificación de SNS que informa que una nueva instancia fue lanzada.

Espero que hayan aprendido mucho, no olviden dejar sus interacciones, preguntas o dudas, pueden utilizar esta arquitectura como base e implementar más funcionalidades y así seguir aprendiendo.

Hasta la próxima.

AWS Solution Architect Associate Exam: Experiencia y Recomendaciones

Javier Madriz — Mon, 27 May 2024 16:33:04 +0000

Hola a todos una vez más. Como les había prometido les contare mi experiencia durante la preparación del examen Solution Architect Associate y como la conseguí.

Que tal me pareció el examen:

Esto quiero que este al inicio porque me parece muy importante. El examen estuvo mas difícil de lo que esperaba, la verdad me sorprendió, cuando presente el examen para el Cloud Practioner termine el examen y tenía la sensación de que había aprobado, sin embargo, en este examen tenía más dudas que certezas, ya les contare por qué.

Si bien es cierto que el examen tiene una estructura definida que se divide en 4 pilares fundamentales que son:

Arquitecturas de Costo Optimizado
Arquitecturas de Alto Rendimiento
Arquitecturas Resilientes
Arquitecturas Seguras

Mi examen particularmente me sorprendió, ya que a pesar de que cubrió estos 4 pilares la mayoría de las preguntas estaban orientadas a serverless o los escenarios planteados tenían inclinación a este tema, les daré un ejemplo para que me entiendan:

Quizá una pregunta en específico quería evaluar mis conocimientos en seguridad, pero el escenario presentado donde se debía implementar los conceptos de seguridad era un ambiente o arquitectura serverless.

Un ejemplo podría ser: Como anonimizar datos con una lambda o como evitar exponer variables de entorno o credenciales en el código de una lambda. Por mencionar cualquier cosa, asi fue la mayor parte del examen. Quiza tenga sentido porque la mayoria de empresas estan apuntando a este tipo de arquitecturas reduciendo esfuerzos operativos y en muchos casos a la larga se puede ahorrar dinero.

Como me prepare:

Como les he contado siempre, no existe un único recurso con la mejor explicación para todo, lo mejor es variar y cuando no te quede claro un concepto buscar información sobre esto en varios recursos, te cuento a continuación los que yo use:

Curso Udemy de Stephane Maarek y Joan Amengual

Este curso es una version en español del mismo contenido del curso en Ingles de Stephane Maarek que es un referente en cuando al aprendizaje de AWS respecta. Por que elegi hacerlo en español y no en ingles como la mayoria recomienda?

Cuando estoy aprendiendo algo nuevo y complejo no me gusta perder ningun detalle, es necesario para mi que las cosas queden claras y no bajo interpretacion y es lo que podria suceder si ves una clase en ingles y el profesor usa un modismo, slang o expresion, utilizada normalmente por hablantes nativos o por quienes conviven con el ingles todos los dias.

Quienes recomiendan hacer el examen en ingles argumentan que podria haber una traduccion mal hecha durante el examen y podrias no identificar el nombre de un servicio, pero la realidad es que ya esto no sucede, mis ultimos dos examenes los he realizado en castellano y el nombre de los servicios son presentados en ingles y el contexto general de la pregunta aparece en español, por lo que no tendras problemas, Es decir que aunque la pregunta este en español el nombre del servicio aparece en ingles, si la pregunta es referente a Glue este aparecera tal cual "Glue" y no como "Pegamento" que es la traduccion, lo que aparecera en español es el contexto general, de igual manera tendras un boton para ir pasando una pregunta a ingles si lo consideras necesario y luego regresar a español.

Laboratorios nivel Solution Architect

Whizlabs aunque tiene video cursos y examenes practicos sobre esta certificacion, te quiero recomendar los laboratorios, si hay algun servicio en el que te gustaria profundizar y conocer desde lo practico, esta es una buena opcion y lo mejor es que puedes comprar unicamente los laboratorios y hacerlos a tu medida, la plataforma te brinda un ambiente de AWS asi que evitaras generar gastos en tu propia cuenta de AWS.

En mi perfil de este blog tambien encontraras algunos laboratorios que podras realizar paso a paso para practicar, estudiar solo de manera teorica no es la mejor forma y puedes aturdirte de tanta teoria.

Participa en charlas en vivo, charlas presenciales, contenido de youtube y lecturas, esto te hara mantenerte inmerso en el aprendizaje y creeme en cualquiera de estos escenarios aprenderas al menos una cosa que no sabias y eso es mas que suficiente, si aprendes al menos una cosa nueva puedes darte por bien servido, te comparto algunos de los que yo use:
AWS Women Colombia.
AWS Security Users Group LatAm
Explicaciones practicas detalladas, por Fernando un ingeniero Devops.

En estos canales de Youtube realizan charlas tecnicas sobre los servicios de AWS, puedes participar en ellas en vivo o ver las que ya estan subidas en youtube, en la mayoria van mas alla de lo teorico y presentan una demo, ademas es una buena opcion para ir haciendo conexiones en Linkedin con quienes impartes estas charlas y que siempre se mantinen compartiendo informacion interesante.

Examenes de practica

Para mi este es el mejor recurso que puedes utilizar como parte final de tu preparacion y te explico porque y como lo utilice yo:

En este punto ya haz visto videos clases, laboratorios, charlas y videos cortos de youtube para aclarar conceptos y es momento de ponerte a prueba en un escenario parecido al que tendras el dia del examen. Te recomiendo que comiences con los examenes bajo revision de 65 preguntas sin sentirte presionado por el cronometro, muchas veces intentamos adivinar y muchas veces acertamos, cuando estes en este escenario aunque hayas acertado marca la pregunta para revision porque aunque acertaste la idea es aprender y este es el mejor momento para hacerlo, puedes filtrar tambien por las preguntas que fallaste y esta es la mejor parte porque te ayudara a repasar esos servicios y cenceptos donde tienes falencias.

No intentes memorizar preguntas, estas preguntas no son iguales a las de un examen, pero si son escenarios similares que te ayudan a desarrollar capacidad de analisis y profundizar donde tienes fallas. Tambien podras ver los resultados del examen por area, asi que si hay un area en especifico donde tienes falencias podras tomar examenes sobre areas especificas, es decir, si la mayoria de tus respuesta erroneas estan dentro de "Arquitecturas resilientes" puedes tomar examenes especificamente para esta area o especificamente para servicios que cubren esta area y a medida que falles tendras una cosa mas en la que aprender, profundizar o repasar, de verdad me encanta este recurso.

Yo realice un recuadro para llevar un control de los examenes de practica que hacia y la puntuacion, te muestro a continuacion:

Despues de cada examen iba anotando la cantidad de preguntas que salieron para cada area, los aciertos, desaciertos y en la ultima columna una proporcion porcentual, el area con puntuacion mas baja era en la que me debia enfocar y profundizar, creeria yo que despues de varios examenes y que estes por encima del 80% de aciertos estas listo para tomar tu examen.

Por ultimo puedes tomar examenes cronometrados para que vayas tomando el tiempo que debes disponer para cada pregunta. En mi casi estuvo un poco ajustado solo me sobraron 7 min en el examen real, lo cual destine para revisar preguntas en las que tenia duda y marque para revisar luego, hubiese preferido tener al menos 20 minutos para esto.

Agenda tu examen

No esperes realizar todos estos pasos para agendar tu examen, porque mientras no exista la fecha compromiso estaras expuesto a procrastinacion y pensamientos de inseguridad. Te recomiendo agendar el examen al menos despues del curso de praparacion, una vez agendado comienza con los examenes de practicas, laboratorios y charlas, para mantenerte inmerso mientras esperas el gran dia para obtener tu certificacion.

Areas o servicios para prestar atencion especial:

Esto es muy variable en cada examen, pero tengamos presente que certificacion estamos presentando o mejor dicho cual no estamos presentando y asi no profundizamos tanto en aspectos que no son relevantes para un arquitecto de soluciones. Te nombrare algunos que para mi son indispensables:

VPC: Este servicio es tan amplio e importante en una arquitectura de nube que merece toda la atencion posible, ademas dentro una VPC existen disintos componentes pertenecientes a diferentes servicios fundamentales dentro de una arquitectura, asi como tambien estos componentes y servicios estan presentes cuando una organizacion y empresa quieren migrar a la nube de manera paulatina, es decir que quieren iniciar con una arquitectura hibrida, en resumen, en mi opinion deberias saber armar una vpc completa desde cero con sus componentes fundamentales, en el curso de preparacion lo explican muy bien, fue mi parte preferida del curso.
Migracion y exportacion de datos: Si usamos la logica el primer paso para llegar a la nube es saber como hacerlo, este punto es la primera pregunta que se hace una empresa cuando el cloud aparece en su radar, pueden comenzar migrando toda su arquitectura, migrando base de datos o migrando datos a servicios epecificos como S3 utilizando dispositivos como lo de la "familia Snow" o utilizando sistema de archivos compartidos como EFS, etc
Seguridad: Si revisas la guia del examen, te daras cuenta que el examen esta dividido en las 4 secciones que ya vimos, con un porcentaje de las preguntas para cada seccion siendo seguridad la seccion con mayor porcentaje, ademas que el principal foco de AWS es la seguridad, es su bandera. Aqui quiero hacer un parentesis, por lo menos en mi examen vi mucho sobre AWS Organizations y cuando yo estudie no le di mucha importancia, pero una empresa madura y con buenas practicas desde el inicio si quiere hacer las cosas bien comienza implementando organizaciones, asi que atencioncon esto.
Serverless y desacople: Recuerden que al inicio les comentaba que serverless fue una constante durante el examen: Esto incluye Lambda, Aurora serverless, DynamoDB, Contenedores y Kubernetes utilizando tecnologia Fargate. En la parte de desacople el predominante es SQS standar y de tipo FIFO, no se olviden los caso de uso para cada una de estas o al menos cuando si o si deben ser de tipo FIFO.

Que no salio en el examen ni por las curvas:

No vi absolutamente nada sobre Machine Learning y hay muchisimos servicios sobre este tema y de hecho en el curso de preparacion se ven la mayoria, no te estoy diciendo que no los revises, es bueno saber al menos para que se utiliza cada servicio, una revision flash estaria bien, no creo que sea necesario ponerte a desarrollar modelos, desplegarlos y construir laboratorios sobre esto, seria lo contrario si presentas una certificacion sobre analitica o la certificacion de "Data Engineer Associate" por eso recalco siempre que tengamos en cuenta cual es la certificacion que vamos a tomar para saber en que merece la pena profundizar, es solo una opinion.

Como presentar el examen y cuando llego el resultado

Para mi es mucho mejor presentar el examen de manera presencial, esto te restara un monton de dificultades que se pueden presentar si tomas el examen online, con situaciones que tu no controlas, como el servicio de internet, un vecino escuchando musica a todo volumen, el venderdor de aguacates o de platanos gritando por la calle "La gente de Colombia y Venezuela" entienden la referencia.

El dia del examen obligatoriamente debes llevar tu documento de identidad principal (ID, Cedula, DNI, Pasaporte) y tambien piden un documento secundario que podria ser (Carnet estudiantil, licencia de conducir, carnet de servicios medicos) etc.

Mientras el resultado no llegaba habia mucha tension en mi, revisaba cada 30 min mi correo y mi perfil de AWS certificate. Aunque AWS estima que los resultados estan listos entre 24 horas y 5 dias, mis resultados llegaron el mismo dia por la noche unas 8 horas despues del examen.

No olvides pasar por aqui

Si utilizas estos recursos, te funcionan y consigues tu certificacion, no olvides compartirlo conmigo en los comentarios, por Linkedin o por donde prefieras, me pondria feliz saber que el tiempo que dedique para hacer este post le sirvio al menos a una persona, cualquier duda o cunsulta durante la preparacion tambien me puedes escribir por aca o por Linkedin.

El proximo paso es construir proyectos en los que pueda utilizar los servicios que mas tienen que ver con mi area "Ingenieria de datos" y por un ladito indagar en los servicios de seguridad y redes que son cosas que me apasionan y que se parecen mucho a lo que hacia antes de hacer el cambio de carrera y que si apunto a un cargo como Arquitecto de soluciones tendria muchas mas posibilidades, todo esto mientras llega una buena oportunidad de trabajo, si en tu empresa hay alguna para mi, no dudes en recomendarme, estaria agradecido.

Hasta la proxima.

AWS Cloud Practitioner Exam: Experiencia

Javier Madriz — Fri, 15 Mar 2024 16:57:06 +0000

¡Hola a todos de nuevo! Aquí estoy una vez más en mi espacio, listo para compartir un poco sobre mis aventuras técnicas y experiencias.

Esta vez, quiero sumergirme en mi preparación y travesía en el examen Cloud Practitioner, el cual conquisté con un sólido puntaje de 883/1000. ¿Nada mal, verdad?

Como me prepare?

La realidad es que no hay un solo recurso definitivo para prepararse para este examen. En mi caso, opté por una variedad de fuentes. Cuando encontraba un concepto que no comprendía completamente o quería profundizar, lo buscaba en diferentes recursos. A continuación, compartiré una lista de los recursos que utilicé y mis opiniones sobre cada uno de ellos.

Curso de Udemy de Stephane Maarek y Joan Amengual

Este curso, impartido por Joan Amengual y basado en el contenido de Stephane Maarek, un reconocido experto en educación sobre AWS, ofrece una versión en español del mismo material. Es la elección perfecta si prefieres tener acceso al contenido completo y detallado sin preocuparte por el inglés. El curso mantiene la misma estructura y recursos gráficos que su contraparte en inglés, lo que garantiza una experiencia de aprendizaje consistente y completa. Aunque puede parecer extenso en un principio, la realidad es que es sumamente completo en su cobertura. Recuerda que no debes ver ningún curso como si fuera una serie de Netflix; en su lugar, cuestiona, reflexiona y toma notas relevantes que te serán útiles para refrescar la memoria cuando lo necesites.

Canal de Youtube de Fernandoing un Arquitecto de Soluciones

Este canal de YouTube se ha convertido en mi favorito. Cuando necesitaba profundizar en algún concepto o practicar, era el recurso perfecto. Ofrece explicaciones claras que van más allá de lo básico, lo cual es fundamental para comprender el "por qué" detrás de las cosas. Recuerda, entender el fundamento es clave para un aprendizaje sólido.

Participar en comunidades activas y en charlas en vivo donde se llevan a cabo talleres y se discuten diversos temas de AWS es una excelente manera de refrescar conocimientos, reforzar lo aprendido y, sobre todo, mantenerse inmerso en el mundo de AWS. A continuación, te comparto algunas recomendaciones para ello.

como practicar luego de la preparacion y agendar el examen?

Es crucial enfrentarse a situaciones similares a las del examen real, y para ello, los simuladores de examen son herramientas indispensables. Entre ellos, destaca un recurso estrella que, en mi opinión, resultó ser de gran ayuda durante mi preparación.

Examenes de prueba en tutorial dojo

Este recurso es, sin duda, la mejor opción para practicar. Ofrece exámenes cronometrados, pruebas por temas específicos y sesiones de revisión sin temporizador.

Cuando realices un examen de práctica, tendrás la oportunidad de revisar las preguntas en las que fallaste y recibir una explicación detallada sobre por qué una opción es correcta y las demás son incorrectas. Además, dispondrás de enlaces a recursos oficiales que respaldan estas respuestas. Este conocimiento resulta fundamental para el examen real. Una recomendación adicional que me resultó muy útil es realizar exámenes bajo revisión. Identifica las áreas en las que tengas más deficiencias y, después de revisar todas las preguntas falladas, realiza un examen centrado en del área específica donde mas tienes problemas. Esto te ayudará a concentrarte y reforzar tus puntos débiles. Además, puedes tomar notas en Notion para llevar un registro de tu progreso.

Finalmente, te recomiendo que realices los exámenes cronometrados para que puedas familiarizarte con los tiempos disponibles en el examen real para cada pregunta. En mi experiencia, descubrí que el tiempo es suficiente y que podía leer con detenimiento sin apresurarme.

Errores frecuentes

Uno de los errores frecuentes que solía cometer en los exámenes de prueba era no darme cuenta de que algunas preguntas requerían más de una respuesta, es decir, eran de respuestas múltiples. En estos casos, si solo seleccionas una opción correcta, aunque sea una de las adecuadas, tu respuesta será considerada incorrecta. Al darme cuenta de esto, empecé a prestar más atención a cada pregunta, verificando primero si era de respuesta múltiple. Cada pregunta de este tipo se indica claramente en negrita con "Marca DOS opciones". Además, noté que las preguntas de respuesta única suelen tener 4 opciones, mientras que las de respuesta múltiple tienen 5 opciones disponibles.

Experiencia con el examen real

El examen lo realicé en un centro de PearsonVue en mi ciudad, de manera presencial. Opté por esta modalidad después de escuchar que los exámenes virtuales pueden generar estrés debido a la monitorización y a las posibles distracciones en casa u oficina.

Es importante llegar al centro de examen con al menos 30 minutos de antelación para completar el registro y la validación de identidad. Se requiere presentar más de un documento que contenga tus datos personales, siendo uno de ellos una identificación con fotografía. Entre los documentos aceptados se encuentran la licencia de conducir, el pasaporte, el carnet estudiantil o una tarjeta médica. En mi caso, llevé mi identificación junto con un carnet de seguro médico.

En general, encontré el examen bastante asequible, considerando la preparación que llevé a cabo. No tengo dudas de que si utilizas estos recursos adecuadamente, lograrás aprobar sin problemas.

Durante el examen, es importante tener en cuenta que puedes responder las preguntas con dudas y marcarlas con una bandera para revisarlas más tarde si dispones de tiempo. Personalmente, seguí este enfoque y terminé el examen en la mitad del tiempo asignado. Luego, dediqué el tiempo restante a revisar las preguntas marcadas y, tras esa revisión, realicé un repaso general rápido de todas las preguntas. Para mi sorpresa, encontré dos preguntas que había respondido incorrectamente y pude corregirlas a tiempo. La moraleja aquí es utilizar todo el tiempo disponible para revisar, sin confiarse ni intentar terminar el examen rápidamente. Este enfoque evitará errores que puedan costarte puntos importantes y asi obtener tu certificacion, recuerda no obtendras un premio adicional por terminar rapido asi que utiliza todo el tiempo.

Temas que no siempre se estudian y que salieron en el examen varias veces.

Well-Architected Framework: A menudo, tendemos a enfocarnos principalmente en aspectos técnicos, al menos en mi caso personal. Sin embargo, si no fuera por los tests de práctica que incluían preguntas relacionadas con este tema, probablemente no habría dedicado tiempo a estudiarlo. De hecho, en el examen me encontré con al menos tres preguntas relacionadas con el Well-Architected Framework.
AWS Cloud Adoption Framework (CAF): Del mismo modo, este tema aborda el proceso inicial que enfrenta una empresa al considerar la migración a la nube y todo el proceso de transformación asociado. Desde una perspectiva lógica, tiene sentido que este tema sea evaluado en un examen como el Cloud Practitioner. De hecho, en el examen encontré al menos dos preguntas relacionadas con este tema. Si hacemos cuentas, serían cinco preguntas en total que no habría podido responder si no hubiera practicado con exámenes de práctica y me hubiera dado cuenta de que estos temas estaban incluidos en el examen real.

Resultados

Después de terminar el examen, me sorprendió ver en la pantalla del computador el estado "APROBADO". Aunque me quedé un tanto dubitativo, ya que no había escuchado ningún testimonio sobre la posibilidad de conocer el resultado en ese momento, decidí no prestarle demasiada atención y esperar la notificación oficial. Esta llegó más tarde ese mismo día por la noche, confirmando que había aprobado el examen con un puntaje de 883. Mi objetivo era alcanzar los 800 puntos, así que me siento satisfecho con el resultado.

Como saber cuando se esta listo?

Te recomiendo que, una vez termines tu curso de preparación, reserves la fecha del examen con al menos tres semanas de anticipación. Esto te dará tiempo suficiente para practicar con exámenes de prueba, realizar laboratorios y revisar material adicional. De lo contrario, es posible que nunca te sientas completamente preparado y te encuentres posponiendo la fecha del examen constantemente debido a las dudas.

Creé un cuadro en Excel donde registraba el número de preguntas acertadas y falladas en cada examen de práctica, así como a qué segmento del examen pertenecían. Esto me permitió identificar las áreas en las que necesitaba reforzar mis conocimientos. Una vez que había alcanzado al menos un 80% de aciertos en todas las áreas del examen, confirmé que estaba listo y que no era necesario postergar más el examen. El día del examen opté por no estudiar; creo que es importante ir relajado, con la mente fresca y la mejor actitud.

El examen está estructurado siguiendo las cuatro áreas específicas que indica la guía de AWS, las cuales puedes ver detalladas en mi Excel.

Como ya tengo mas experiencia y he construido soluciones en AWS y ademas tambien me prepare para el examen Solution Architect Associate en unas semanas lo presentare y les contare que tal estuvo, la meta es obtener 3 certificaciones en 2024 y ya logramos la primera.

Si lo que leiste aqui te sirvio de algo para tu examen no dudes en compartirmelo, me haria muy feliz saber que ayude a alguien.

Hasta la proxima.

Eficiencia Analítica en la Nube: Taller Práctico con RDS, S3, Glue y Athena en AWS

Javier Madriz — Mon, 26 Feb 2024 13:27:57 +0000

Saludos a todos en esta emocionante entrega de laboratorios de AWS! En esta sesión, trabajaremos juntos para construir una solución integral en AWS.

Que aprenderemos?

Seguridad avanzada: Utilizaremos AWS Key Management Service (KMS) para encriptar una instantanea de base de datos.
Almacenamiento en S3: Crearemos un Bucket de S3 a donde exportaro.
snapshot: Crearemos una copia de una base de datos MySQL.
Exportar la copia de seguridad o snapshoot a un Bucket S3.
Descubrimiento de metadatos: Aprovecharemos el rastreador de AWS Glue para descubrir y almacenar metadatos en el Catálogo de datos.
Consultas eficientes: Athena utilizará estos metadatos para ejecutar consultas SQL directamente sobre nuestros datos almacenados en S3.

Para aquellos que aún no han creado una base de datos, les recomiendo seguir nuestro laboratorio anterior Crea una base de datos en RDS paso a paso

1. Creacion de una Llave KMS para cifrado.

Ubiquemos el servicio KMS dentro de la consola de AWS.
Estando alli pulsaremos "Crear clave".
Elige el tipo de clave como "Simétrico"; esto implica que la clave servirá tanto para cifrar como para descifrar.

Asigna un nombre a la clave y opcionalmente, proporciona una descripción que facilite la identificación de su propósito.
Por ahora, dejaremos las demás configuraciones en sus valores predeterminados. Posteriormente, concederemos permisos a usuarios y roles para que puedan utilizar esta clave.

2. Crear Bucket S3

Ubiquemos el servicio de S3 en la consola de AWS y elijamos crear Bucket.
La región será Norte de Virginia (us-east-1). Asigna un nombre al bucket; en mi caso, lo nombraré "copy-for-analitica". Deja las demás configuraciones como predeterminadas, ya que, por ahora, no necesitamos que nuestro bucket sea de acceso público, tampoco requerimos versionado ni ninguna configuración avanzada.

Dado que este bucket será el destino de copias de seguridad, como buena práctica, podríamos acceder al bucket y crear un directorio específico para nuestra base de datos.

3. Creemos la copia de la Base de datos

Vayamos al servicio RDS y ubiquemos nuestra base de datos, si no tienes una, te recuerdo que ya hice un laboratiorio practico para esto Crea una base de datos en RDS paso a paso
Selecciona la base de datos, haz clic en el botón de acciones y elige "Realizar instantánea".

Asigna un nombre a la instantánea en mi caso la llame "snap-MyDB", click en el boton "Crear". Ten en cuenta que esta acción suele demorar unos minutos.

Exportacion de Instantanea al Bucket S3.

Una vez creada la instantanea la seleccionamos y hacemos click en el boton "Acciones" y elegimos la opcion "Exportar a Amazon S3"

Ingresa un identificador para la exportacion, no es mas que un nombre.
En la seccion "datos exportados" queremos exportar la totalidad de nuestros datos, ya que tambien existe la opcion de exportaciones parciales.
En la seccion "Destino de S3" elige el bucket que creamos anteriormente en mi caso lo llame "copy-for-analitica" y en el campo "prefijo" va el nombre de la carpeta donde insertaremos esta exportacion.
En la seccion de "Rol IAM" crearemos un nuevo rol, solo asignale un nombre al rol, este por defecto se crea con politicas que permiten insertar datos en S3.
En la seccion "Cifrado" vamos a elegir la clave KMS que creamos al inicio. La clave de cifrado se utiliza para cifrar los datos antes de ser almacenados en el bucket de S3. Esto proporciona una capa adicional de seguridad, especialmente cuando los datos son sensibles o confidenciales.
Procede a realizar la exportacion, esto puede demorar entre 20 y 25 minutos, dependiendo de la cantidad de datos.

Revisemos el Bucket S3

Ahora, al explorar nuestro bucket 'copy-for-analitica', dirigimos la mirada hacia el directorio 'copy-MyDB'. Aquí, encontramos la instantánea que acabamos de exportar, identificada por el nombre asignado durante el proceso de exportación. Este paso confirma el éxito de nuestra tarea, proporcionando una organización ordenada y accesible para nuestros datos en la nube.

Crear Crawlers (rastreador) de Glue.

Al dar este paso, estamos configurando un rastreador en AWS Glue. Este rastreador nos brinda la capacidad de extraer metadatos esenciales de la copia de nuestra base de datos, que actualmente reside en el bucket S3. Estos metadatos son fundamentales para facilitar consultas analíticas desde Athena en etapas posteriores del proceso. Esencialmente, estamos preparando el terreno para una exploración eficiente y detallada de nuestros datos almacenados en la nube.

Ubiquemos el servicio Glue desde la consola, recuerda que puedes hacer uso de la barra de busqueda.
Una vez alli, en la columna izquierda, seccion "Data catalog" busca la opcion "Crawlers"

Crear crawlers, asignale un nombre y una descripcion, click a "Siguiente".
Veremos la seccion de "Data Sources" donde corresponde agregar la fuente de los datos de donde el crawler obtenedra la metadata, en nuestro caso es un bucket de S3.

Al pulsar "Add sources" se abrira una ventana donde especificaremos "S3" como origen de los datos, navegaremos dentro de las opciones de "S3" para elegir nuestro Bucket, tambien puedes insertar la ruta donde se encuentra el bucket.
Tambien elegiremos la opcion de rastrear todas las subcarpetas que existan dentro del bucket y hacemos click en "Agregar fuente de datos" para finalizar esta tarea.

Agregada la fuente, pasamos al siguiente paso, donde crearemos un rol, solo debemos asignarle un nombre y este se creara con los permisos necesarios para que el crawler acceda a S3, colocar un nombre descriptivo puede ser buena practica para identificar o reutilizar, click en "Siguiente"
Ahora debemos agregar una base de datos, click en "Agregar base de datos", hagamos un parentesis aqui:

Esta base de datos actúa como un repositorio organizado para los metadatos extraídos por el rastreador, incluyendo información sobre tablas y columnas. La creación de esta base de datos no solo estructura de manera ordenada la información, sino que también facilita la realización de consultas analíticas más efectivas en Athena en fases posteriores del proceso.

Te recomiendo no usar caracteres especiales para evitar inconvenientes al momento de lanzar consultas SQL.

Después de crear la base de datos, simplemente la seleccionamos como nuestra base de datos objetivo, manteniendo las configuraciones predeterminadas para el resto. esto funcionara asi: El rastreador se dirige a S3, recupera la informacion, y l almacena en la recién creada base de datos en el Catálogo de AWS Glue.

Hacemos una revision de todos los parametros establecidos y click en "Crear crawler"

Creado el Crawler, no queda mas que ejecutarlo o correrlo en la opcion "Run crawler" para que cumpla con su funcion ya explicada anteriormente.

5. Habilitar el Crawler para Utilizar Nuestra Clave KMS.

En este paso, permitiremos que nuestro rastreador (Crawler) haga uso de la clave de AWS Key Management Service (KMS) que hemos configurado. Sigue estos pasos:

Accede a AWS Key Management Service (KMS) y busca la clave correspondiente haciendo clic sobre ella.
Desplázate hasta la sección de 'Usuarios y Claves' dentro de la configuración de la clave KMS.
Agrega el rol asociado a nuestro rastreador a la lista de usuarios autorizados para utilizar esta clave. Esto garantiza que el rastreador tenga los permisos necesarios para interactuar con KMS y usar la clave para desencriptar la información almacenada durante el proceso de rastreo en nuestro bucket S3.

6. Consultas SQL desde Athena

Con toda la configuración completada, ahora podemos realizar consultas SQL directamente desde Athena. Vamos a dirigirnos a la consola de AWS y ubicar el servicio Athena para comenzar a explorar y analizar nuestros datos de manera eficiente.

Recordemos que debenos correr el crawler o rastreador.
Si ya ejecutaste el crawler, al ingresar a Athena ya podremos ver nuestra base de datos en la seccion de origen de los datos y la cual ya se encuentra en el Data Catalog.

Antes de realizar una consulta es necesario ir a la pestaña de "configuracion" luego "Administracion" y establecer un destino para los resultados que arrojen las consultas que hagas, este puede ser el mismo bucket que creamos, puedes opcionalmente crear un directorio especificamente para eso dentro del bucket y entonces colocar la ruta junto con su prefijo que es el nombre de la carpeta.

7. Hagamos un par de consultas

Obtengamos todos nuestros registros

SELECT *  FROM mydb;

Obtengamos los usuarios mayores de 30 años**

SELECT * FROM mydb
WHERE edad > 30;

Como pueden observar todo salio perfecto, de hecho si revisas el bucket podras ver que los resultados de las consultas se estan guardando y estos resultados puedes utilizarlo para crear visualizacion con Quicksight por ejemplo, es una idea que puedes implementar despues de este taller.

Conclusion

En este laboratorio práctico, hemos explorado cómo realizar consultas SQL sin afectar el rendimiento de la base de datos, utilizando servicios clave de AWS como RDS, S3, KMS, Glue y Athena. Esta metodología es esencial en el análisis de datos y destaca la capacidad de consultar datos analíticos sin impactar la operatividad de la base de datos.

Es posible Considerar la automatización y la actualización de datos en S3 cuando ingresan a la base de datos principal. Esta capacidad de automatización brinda una solución eficiente y dinámica, facilitando la eficiencia y agilidad en el análisis de datos continuo.

Espero que hayan disfrutado del contenido. ¡Anímense a interactuar con el post y, si desean realizar algún incentivo económico, aquí están mis datos habituales

Paypal: ** unpagopaypal@gmail.com
**Binance Pay: 213182157

AWS RDS: Crea tu Base de Datos y Realiza tus Primeras Consultas en un Laboratorio Práctico

Javier Madriz — Wed, 21 Feb 2024 13:51:15 +0000

¡Hola a todos! En este emocionante laboratorio, les guiaré paso a paso en la creación de una base de datos utilizando Amazon RDS. Desde la configuración inicial hasta su primera consulta SQL, exploraremos juntos cada detalle. Prepárense para sumergirse en el fascinante mundo de las bases de datos y descubrir cómo hacerlo con Amazon RDS. ¡Vamos allá!

Comencemos revisando la definición de RDS como servicio:

Amazon Relational Database Service (Amazon RDS) es un conjunto de servicios administrados que simplifican las tareas de configuración, operación y escalado de bases de datos en la nube. Ofreciendo opciones flexibles, puedes elegir entre siete motores populares, como Amazon Aurora (compatible con MySQL y PostgreSQL), MySQL, MariaDB, PostgreSQL, Oracle y SQL Server. Además, puedes implementar en instalaciones locales con Amazon RDS en AWS Outposts

Ahora que hemos entendido el concepto de Amazon RDS, veamos los requisitos para completar este taller:

Una cuenta de AWS
Instala MySQL y su Workbench para contar con la interfaz gráfica necesaria para conectar a tu base de datos y ejecutar consultas.
También puedes optar por instalar cualquier interfaz de base de datos de tu preferencia. En mi caso, utilizaré SQLECTRON, ya que es más sencillo, menos pesado y suficiente para este taller. Puedes descargarlo aquí

Comencemos.

Comencemos creando un grupo de seguridad para nuestra base de datos, el cual definirá las reglas de tráfico entrante y saliente. Iniciaremos sesión en la Consola de AWS y buscaremos el servicio EC2. Si no lo tienes agregado como favorito, puedes utilizar la barra de búsqueda para encontrarlo.

Una vez estando en la consola de EC2, en la columna izquierda ubicamos la sección de Redes y Seguridad y seleccionamos la opción Security Groups.
Asigna un nombre al grupo de seguridad; es buena práctica que sea descriptivo según la finalidad. En mi caso, le pondré DB-SG.
Opcionalmente, puedes agregar una descripcion que consideres clave para identificar su SG.
Para este taller, usaremos la VPC por defecto.
Vamos a la sección de reglas de entrada en la parte inferior y seleccionamos el botón Agregar Regla. Este es un paso crucial al momento de crear un grupo de seguridad.

Como podemos apreciar en la imagen, para "Tipo" se especifica el protocolo para el tráfico de red. En nuestro caso, vamos a elegir mysql-aurora (Es lo que corresponde para una base datos mysql) y automáticamente se seleccionará el puerto 3306, si crearas una DB con un motor distinto solo debes cambiarlo.
En "Fuente-Source" para este taller elegiremos cualquier fuente, esto quiere decir que nuestro grupo de seguridad permite trafico de entrada desde cualquier recurso, en otros talleres aprenderemos buenas practicas y consideraciones a tener en cuenta para este aspecto.
Ya podemos presionar el boton "Crear grupo de seguridad"

Es hora de crear nuestra base de datos. Encuentra el servicio de RDS en la sección de favoritos si ya lo agregaste, o encuéntralo utilizando la barra de búsqueda, similar a como lo hicimos con EC2 en pasos anteriores.

Estando en la consola de RDS, en la columna izquierda seleccionamos "Bases de datos" y luego elegimos "Crear base de datos.

Elige el modo de creación: Standard o Sencilla. Con el modo "Standard", puedes personalizar configuraciones como seguridad y alta disponibilidad etc. En el modo "Sencilla", se utilizan configuraciones recomendadas por defecto, algunas modificables después de la creación. Te recomiendo seleccionar Standard para un mayor control y comprensión detallada.
Para este taller, usaremos una base de datos MySQL, como lo especificamos en el grupo de seguridad.

La versión del motor se puede dejar seleccionada por defecto. Al momento de hacer este taller, está en MySQL 8.0.35. Puedes cambiarla si así lo requieres.
Continuamos con la sección de plantillas. Elegiremos la opción "Capa gratuita" para evitar costos adicionales e innecesarios para este taller. En este momento, es crucial activar tu curiosidad y aprender sobre las diferencias entre las opciones disponibles. Al elegir entre "Producción" o "Pruebas y desarrollo", notarás que se activa la sección de "Disponibilidad y Durabilidad" que para nuestro objetivo no es necesario.

Nos dirigimos a la sección de configuración, donde estableceremos un identificador de instancia de la base de datos. Este identificador es el nombre único para tu instancia de base de datos y debe ser diferente a cualquier otra instancia que tengas en tu cuenta. Importante: este nombre identifica la instancia de la base de datos, no es el nombre de tu base de datos en sí, yo le coloque "instances-dbmysql"
Luego, asignaremos un nombre de usuario root y una contraseña. Por ejemplo, yo le colocaré "javidev". Asegúrate de elegir un nombre de usuario y una contraseña segura.

Continuamos con la sección de "Configuración de la instancia", donde seleccionaremos "Clases con ráfagas". Esto incluye las instancias de tipo t2.micro y t3.micro, que están dentro de la capa gratuita. Es importante recordar que del tipo de instancia depende la capacidad de procesamiento, rendimiento y transaccionalidad de la base de datos. Recomiendo leer más sobre las familias y tipos de instancias si quieres profundizar un poco mas, para este taller elegiremos t3.micro.

Continuamos con la sección de 'Almacenamiento', donde dejaremos la configuración por defecto. Esto implica un tipo de almacenamiento SSD de uso general (Gp2) con un valor mínimo de almacenamiento de 20GB. Es importante destacar que en el tipo de almacenamiento, podemos establecer un equilibrio entre rendimiento y costos, dependiendo de los requerimientos.
En la sección de 'Escalado automático', vamos a deshabilitar esta opción, ya que no necesitamos esta personalización en este taller. Esta característica se utiliza para permitir que, cuando tu base de datos alcance un umbral establecido por ti, pueda escalar automáticamente sin intervención manual.

Llegamos a la seccion de conectividad donde dejaremos la informacion por default, solo cambiaremos el Grupo de seguridad por default por el grupo de seguridad que creamos al inicio, en mi caso de nombre DB-SG y tambien habilitaremos el acceso publico, este ultimo paso muy importante para este taller.
En la zona de disponibilidad, puedes dejarla sin preferencia, pero en mi caso, usaré us-east-1a para tener control y, quizás en otros talleres, permitir que algunos recursos en la misma zona de disponibilidad puedan interactuar con mi base de datos.

En configuracion adicional dejaremos el puerto 3306 (Puerto TCP/IP que la base de datos usará para las conexiones de las aplicaciones.)
En la sección de autenticación a base de datos, seleccionaremos 'Contraseña'. Ya asignamos previamente un usuario y contraseña. Aunque esta no es la única opción disponible, podriamos profunfizar en las otras opciones en laboratorios futuros.
Vamos a la sección de configuración adicional. Atención aquí, ya que en este paso estamos estableciendo un nombre inicial para nuestra base de datos. Si no especificamos ninguno, no se creará la base de datos. En ese caso, solo se crearía la instancia de base de datos, y tendríamos que acceder a ella posteriormente para crearla, asi que nosotros si estableceremos uno.
Deshabilitaremos la opcion de copias de seguridad automatizadas, para este taller no las necesitamos.

Lo demás puede quedar con la información por defecto. Si tienes alguna pregunta sobre algún punto, déjame tus comentarios o investiga por tu cuenta. Al final, veremos un resumen del costo de la base de datos. Recuerda que AWS tiene su capa gratuita, y si aún estás dentro de ella, este costo no se generará. Si no estás seguro, puedes completar el taller y luego eliminar la base de datos sin ningún costo."

Ahora, le damos al botón 'Crear base de datos'. Esto tomara algunos minutos y ¡Listo! Ya tenemos nuestra base de datos lista para cargarle datos y lanzar consultas.

Hagamos clic en nuestra base de datos y vayamos hasta la sección 'Conectividad y seguridad'. Allí encontraremos un resumen e información que necesitaremos para establecer la conexión, como el 'Punto de enlace' y el 'Puerto'. Copiemos esta información y abramos SQLECTRON o la interfaz de base de datos que hayas descargado.

Establezcamos conexión:

En el campo 'Name', establecemos un nombre para la conexión.
En 'Database type', elegimos MySQL, que es el motor de nuestra base de datos.
En 'Server Address', colocamos el punto de enlace copiado en la sección anterior en 'Conectividad y seguridad' de nuestra base de datos en AWS.
Automáticamente, el puerto se establecerá en el 3306.
Colocamos el usuario y la contraseña que estableciste al momento de crear la base de datos, así como también el nombre de la base de datos.
Si estás utilizando Sqlectron, puedes hacer clic en el botón 'Test' para asegurarte de que todo esté bien antes de guardar la conexión y conectarte. Si la prueba es exitosa, ya puedes guardar la conexión. En caso contrario, si la prueba no pasa, es posible que hayas ingresado algún dato incorrecto. En este momento, es hora de revisar con calma sin caer en pánico.

Es hora de conectarse a la base de datos y empezar a crear tablas, cargar informacion y hacer consultas.

USE MyDB; #Estamos indicando que base de datos queremos usar

Ahora creemos la tabla users:

CREATE table users(name VARCHAR(55), lastname VARCHAR(55), edad INT);

Insertemos algunos datos:

INSERT INTO users(name, lastname, edad)
VALUES
INSERT INTO Persona (nombre, apellido, edad) VALUES
('Juan', 'Pérez', 25),
('María', 'Gómez', 30),
('Carlos', 'López', 22),
('Laura', 'Martínez', 28),
('Pedro', 'Rodríguez', 35),
('Ana', 'Hernández', 26),
('José', 'Díaz', 40),
('Sofía', 'Sánchez', 32),
('Miguel', 'Flores', 28),
('Isabel', 'García', 29);

Hagamos una consulta a la tabla users

SELECT * FROM users;

Miremos el resultado

Todo salio de lujo? Felicidades, lo haz logrado

En este taller, hemos logrado juntos la creación de un grupo de seguridad, la configuración de una base de datos MySQL, el establecimiento de conexión, la creación de la tabla 'users', la carga de datos y el lanzamiento de consultas. Este es solo el comienzo de nuestro viaje de aprendizaje.

El siguiente taller

En los próximos días, nos sumergiremos en una práctica avanzada utilizando la misma base de datos. Crearemos una copia de seguridad, la exportaremos a S3 y aprovecharemos servicios como Glue y Athena para lanzar consultas on-demand. Esta estrategia de análisis es una práctica valiosa, ya que nos permitirá realizar consultas sin afectar el rendimiento de la base de datos principal. ¿Te animas a aceptar este desafío y explorar nuevas dimensiones en el mundo de la analítica de datos en la nube? ¡Espero con entusiasmo seguir aprendiendo y explorando contigo!

Si consideras que este taller fue útil, te brindó nuevos conocimientos o despertó tu interés por AWS, y deseas contribuir de alguna manera, aquí hay varias opciones: interactúa con este post, compártelo, y si deseas hacer una contribución monetaria, a continuación encontrarás mis datos de PayPal y Binance.

Paypal:
unpagopaypal@gmail.com

Binance Pay
Id de pay: 213182157

Hasta la proxima.

AWS ALB + Sticky Sessions Configuración y Casos de Uso

Javier Madriz — Tue, 16 Jan 2024 21:28:29 +0000

En este post, exploraremos a fondo la configuración de AWS ALB con la función de Sticky Sessions habilitada y examinaremos escenarios prácticos donde esta configuración es esencial.

¿Qué es un ALB o Application Load Balancer?

Para comprender la importancia de la configuración de Sticky Sessions, es crucial repasar la función fundamental de un Application Load Balancer (ALB) en nuestra infraestructura. Este dispositivo desempeña un papel central al recibir las solicitudes de los usuarios destinadas a nuestra aplicación. Luego, de manera inteligente, distribuye estas peticiones entre las instancias disponibles que conforman nuestra aplicación, con el objetivo de optimizar el rendimiento. Este proceso se basa en la evaluación constante de la capacidad de cada instancia en tiempo real, asegurándose de dirigir el tráfico hacia instancias saludables y disponibles.

Que es Sticky Session y para que sirve?

Las Sticky Sessions, o sesiones persistentes, juegan un papel fundamental en la optimización del rendimiento de una aplicación. Esta funcionalidad permite que un usuario sea dirigido continuamente a la misma instancia de servidor durante un período de tiempo predefinido. La implementación de Sticky Sessions se logra mediante la asignación de una cookie específica que contiene información crucial sobre la instancia a la cual se debe dirigir el tráfico del usuario. Esta estrategia se traduce en una experiencia más coherente para el usuario, ya que mantiene la conexión con la misma instancia, facilitando la persistencia de datos y la continuidad en la interacción con la aplicación.

¿Cuáles serían algunos casos de uso?

La configuración de Sticky Sessions se torna imprescindible en escenarios específicos, como el comercio electrónico, donde la consistencia en la experiencia del usuario es crucial. Imaginemos un usuario que ha avanzado en su proceso de compra, llenando su carrito con productos. En una situación convencional, si el usuario actualiza la página o realiza una nueva petición, podría ser dirigido a una instancia diferente del servidor, perdiendo así la información del carrito de compras previamente configurado. No obstante, con la configuración de Sticky Sessions habilitada, durante el periodo definido, todas las peticiones del usuario se redirigirán a la misma instancia, asegurando que la información del carrito de compras se mantenga intacta. Este nivel de persistencia es fundamental para ofrecer una experiencia de compra fluida y sin interrupciones, incluso en situaciones donde el usuario realiza acciones adicionales o actualizaciones en la interfaz. En resumen, la funcionalidad de Sticky Sessions se convierte en un aliado estratégico para preservar la continuidad y consistencia en el proceso de compra en línea.

Laboratorio de práctica: Configuración de Sticky Sessions en AWS ALB

En este laboratorio, guiaremos paso a paso la creación de una pequeña infraestructura en AWS para poner a prueba la funcionalidad de Sticky Sessions en un Application Load Balancer (ALB).

Inicia sesion en la consola de AWS yo eligire la region de Virginia para este taller,ubicate en el servicio EC2 desde alli podras desarrollar todo lo necesario.

Tarea 1 Comenzaremos creando un grupo de seguridad SG que permita tráfico de entrada HTTP, ubícate en la columna izquierda en la sección de redes y seguridad y veras la opción grupos de seguridad.

Asigna el nombre SG-ALB-MyApp al grupo de seguridad. Agrega una descripción opcional para mayor claridad.
En la opción "VPC", puedes dejar la VPC predeterminada para efectos de esta práctica.
Selecciona "Agregar regla de entrada". En la sección "Tipo", elige HTTP. En "Origen o Fuente", selecciona Anywhere IPv4 para permitir el tráfico de entrada desde cualquier lugar.
Haz clic en "Crear grupo de seguridad" para finalizar la creación del grupo.

Tarea 2 Crearemos un par de instancias que luego incluiremos en el grupo destino al cual apuntara nuestro ALB, así que estando en el servicio EC2 en la consola ubícate en la columna izquierda en la opción instancia y luego selecciona lanzar instancia.

Comencemos con la configuración de nuestra instancia, esta instancia la llamare instance-01 y utilizare la AMI de Amazon Linux que será el S.O de la instancia.
En tipo de instancia eligiremos la t2.micro que es más que suficiente para completar esta actividad.
En par de claves, elegiremos la opción proceder sin par de claves, ya que para efectos de este taller no es necesario.

Nos detendremos en Configuración de redes y le daremos a la opción editar, donde seguiremos usando la VPC por default de AWS, en subnet elegiremos la zona de disponibilidad us-east-1a que será la ubicación donde estará nuestra instancia, la asignación de dirección ip publica también la dejaremos habilitada y en grupos de seguridad seleccionaremos uno existente que sera el grupo de seguridad que creamos en el inicio y llamamos SG-ALB-MyApp.
Ahora iremos hasta detalles avanzados donde colocaremos estas pequeñas lineas de codigo que sera una configuracion inicial con la que se lanzara la instancia justamente en el apartado User Data

#!/bin/bash
sudo su
yum update -y
yum install httpd -y
echo "<h1>Hola mundo desde instance-01 $(hostname -f)</h1>" > /var/www/html/index.html
systemctl start httpd
systemctl enable http

Y procedemos a lanzar nuestra primera instancia.

Lanza la segunda instancia siguiendo los mismos pasos asignandole el nombre instance-02 y en el script de user data recuerda tambien colocarle ese nombre que nos servira para diferencia cuando nuestra peticion se dirigida a una instancia u otra por el ALB

#!/bin/bash
sudo su
yum update -y
yum install httpd -y
echo "<h1>Hola mundo desde instance-02 $(hostname -f)</h1>" > /var/www/html/index.html
systemctl start httpd
systemctl enable http

Tarea 3 Crearemos nuestro grupo destino el cual estara compuesto por las instancias creadas anteriormente:

Desde la seccion de EC2 en la columna izquierda nos ubicamos en el apartado de balanceadores de carga y eligiremos Grupos de destino y le damos crear.

En la primera sección, no es mucho lo que haremos. El tipo de grupo objetivo será de tipo instancia. Asignaremos un nombre a nuestro grupo objetivo; podría ser TG-MyApp. El resto de esta sección puede quedar con los valores predeterminados, y pulsamos "Siguiente".
Para registrar objetivos en nuestro grupo, veremos un listado donde aparecerán nuestras instancias, las cuales debemos seleccionar y darle al botón de "Incluir como pendiente".

En este punto ya veremos el listado de las instancias que hacen parte de nuestro grupo objetivo y procedemos a darle "Crear grupo objetivo".

Tarea 4 Llego el momento de crear y configurar nuestro Application Load Balancer ALB.

Seguimos dentro del servicio EC2 en nuestra consola, columna izquierda, seccion Balanceadores de carga y Create Load Balancer
En el siguiente paso deberemos elegir el tipo de Balanceador de carga ya que en este momento hay 3 tipos, como lo hemos mencionado en todo el tutorial crearemos un ALB asi que esa es la opcion a elegir, dale al boton "Crear".
Asignamos un nombre a nuestro balanceador de carga, ALB-MyApp, lo cual es apropiado para este ejemplo. En el esquema, seleccionamos "Internet-facing", lo que significa que está expuesto a Internet y puede recibir solicitudes a través de Internet y en direcciones IP, Elegimos "IPv4"

En el apartado de redes, dejamos la VPC por defecto, ya que es la que estamos utilizando. Debemos elegir al menos dos zonas de disponibilidad a las cuales nuestro ALB podrá redirigir tráfico. Esto brinda alta disponibilidad en infraestructuras, en caso de que deseemos tener nuestra aplicación en varias zonas de disponibilidad. En este caso, seleccioné us-east-1a y us-east-1b. Recuerda que nuestras instancias las creamos en us-east-1a, es decir, que esta debe ser una de las zonas de disponibilidad a las cuales debe apuntar nuestro ALB.
En Grupos de seguridad elegiremos nuestro grupo de seguridad SG-ALB-MyApp
En el apartado de Listeners, vamos a seleccionar nuestro grupo objetivo TG-MyApp. Recordemos que este grupo objetivo es el que recibirá el tráfico distribuido por nuestro ALB, y dicho grupo objetivo está compuesto por nuestras dos instancias.

Al final de la seccion podremos ver un resumen y crear nuestro ALB.

Llego el momento de hacer pruebas...
Con todos nuestros recursos en pleno funcionamiento, es hora de iniciar las pruebas y observar el rendimiento de nuestra infraestructura.

Seleccionemos nuestro ALB previamente creado y, en la sección de detalles, copiemos su DNS name y peguémoslo en el navegador.

En este punto, ya visualizaremos nuestra aplicación web. Si enviamos peticiones en reiteradas oportunidades mediante el botón de "Refresh" en el navegador, observaremos cómo nuestro balanceador de carga direcciona tráfico a ambas instancias, las cuales identificamos en el script que colocamos en user data al momento de lanzarlas.

Habilitar la funcionalidad de Sticky Session
En esta tarea, habilitaremos la funcionalidad de Sticky Session editando los atributos de nuestro grupo de destino. Esto asegura que las solicitudes futuras del mismo cliente siempre se redirijan a la misma instancia dentro de una ventana de tiempo específica, manteniendo la consistencia de datos y proporcionando una experiencia de usuario óptima.

Para comenzar nos ubicamos en la seccion balanceadores de carga de la columna izquierda, seleccionamos grupo de destino, seleccionamos nuestro TG-MyApp, en la parte inferior seleccionamos la pestaña atributos y le damos al boton "Editar".
Ahora, nos dirigimos a la parte inferior y activamos la funcionalidad de Sticky Sessions colocándola en modo ON. En el tipo, seleccionamos que las cookies sean generadas por el ALB. Para esta práctica, estableceremos una ventana de tiempo de 2 minutos, como se muestra en la siguiente imagen.

Realizado esto, puedes utilizar nuevamente el DNS name del ALB para enviar peticiones. Al hacerlo en varias ocasiones, notarás que serás redirigido siempre a la misma instancia. Esto se debe a que el sistema detecta que eres el mismo usuario y que aún estás dentro de la ventana de tiempo establecida. Solo dirigirá el tráfico a la otra instancia después de que haya transcurrido el periodo de dos minutos que hemos establecido en este caso. Puedes ajustar la duración de estas ventanas de tiempo según tus preferencias, ya sea optando por ventanas más cortas o más largas

Espero que te hayas animado a realizar este laboratorio. Recuerda que la práctica y la enseñanza consolidan el conocimiento. No olvides dejar cualquier comentario; también aprendo de ustedes. Comparte este post, a alguien le puede ser útil. Hasta la próxima.

Aprende como montar un volumen EBS en tu instancia de Linux en AWS.

Javier Madriz — Sat, 14 Oct 2023 03:03:35 +0000

A lo largo de este post, de manera muy sencilla, aprenderás cómo montar un volumen EBS en una instancia de Linux en AWS. Asumiré que ya sabes cómo crear una instancia, un volumen EBS y asociarlo a dicha instancia.

Pero ya sabemos que no basta con asociar el volumen a la instancia; debemos hacer el montaje del volumen, y aquí lo haremos paso a paso:

Paso 1: Procedemos a conectarnos a nuestra instancia. Para esto, puedes utilizar la AWS CLI o Instance Connect.

Paso 2: Crearemos el directorio donde queremos montar nuestro volumen. En este artículo, lo haremos en el directorio /mnt y lo llamaremos mi_volumen. Ejecutamos el siguiente comando:

sudo mkdir /mnt/mi_volumen

Paso 3: Verificamos que el volumen que asociamos ya existe en nuestro sistema. Lo hacemos de una manera sencilla con el comando

lsblk

Podemos ver nuestro volumen xvdf de 4GB en el output anterior.

Paso 4: Debemos formatear nuestro volumen antes de montarlo. Esto significa prepararlo para su uso al establecer la estructura y las tablas de metadatos necesarias. Lo haremos con el siguiente comando, utilizando el sistema de archivos ext4:

sudo mkfs -t ext4 /dev/xvdf

La salida indicará que el comando ha formateado con éxito el dispositivo /dev/xvdf con el sistema de archivos ext4, y el sistema de archivos ahora está listo para su uso. Los datos que se almacenen en este dispositivo se guardarán en el sistema de archivos ext4 que acabas de crear.

Paso 5: Ahora procedemos a realizar el montaje de nuestro volumen xvdf en el directorio que creamos al inicio llamado mi_volumen. Lo hacemos con el siguiente comando:

sudo mount /dev/xvdf /mnt/mi_volumen

Verifiquemos el montaje con el comando

df -h

Deberías ver una línea que muestra el dispositivo y el punto de montaje que configuraste.

Paso 6: Ahora configuraremos que el montaje sea persistente cuando se reinicie o se detenga la instancia. De lo contrario, tendrías que hacerlo de manera manual cada vez que reinicies o detengas la máquina. Esa persistencia se hace accediendo al siguiente archivo:

sudo nano /etc/fstab

una vez dentro del edito agregaras la siguiente linea:

/dev/xvdf  /mnt/mi_volumen ext4 defaults 0 0

No olvides usar el nombre de EBS y del directorio que creaste y donde hiciste el montaje cuando vayas a ejecutar las lineas de codigo.

En este punto ya tienes tu volumen EBS montado y aca podrias hacer algunas pruebas como crear archivos y datos, reiniciar tu instancia y volver a iniciar para observar la persistencia de los datos, hay mucho por aprender y probar, asi que adelante.

Por otra parte, sabias que un EBS que no fue cifrado y que adjuntaste a una instancia podrias cifrarlo teniendo en cuenta los datos que ya existen y los que estan en transito? si te parece interesante y quieres saber como se hace, dejalo en los comentarios.