<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>AWS Route 53 ARC – Detección y Failover Automático :: Español</title>
    <link>https://aws-route53-labs.rofriday.com/index.html</link>
    <description>AWS Route 53 ARC Detección de Caídas y Failover Automático ¿De qué trata este workshop? En este workshop aprenderás a construir una solución de alta disponibilidad para un sitio web estático usando servicios nativos de AWS. El objetivo no es recuperación ante desastres: es que el sistema detecte solo cuando el sitio principal cae, notifique a los equipos correspondientes vía SNS → Email / SMS, redirija el tráfico a una página de mantenimiento, y tenga un mecanismo para volver al sitio primario cuando esté recuperado.</description>
    <generator>Hugo</generator>
    <language>es-ES</language>
    <atom:link href="https://aws-route53-labs.rofriday.com/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Lab 0: Prerrequisitos</title>
      <link>https://aws-route53-labs.rofriday.com/00_prerequisitos/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://aws-route53-labs.rofriday.com/00_prerequisitos/index.html</guid>
      <description>Lab 0: Prerrequisitos Antes de comenzar, asegurémonos de tener todo lo necesario para ejecutar este workshop de principio a fin sin interrupciones.&#xA;Lo que necesitas Recurso Detalle Cuenta AWS Con permisos de administrador (o el conjunto de permisos detallado abajo) Dominio propio (opcional) Para usar un nombre real en Route 53 (si no tienes, usaremos direcciones directas) Email válido Para recibir notificaciones SNS Número de teléfono (opcional) Para notificaciones SMS vía SNS Región recomendada Aviso AWS Route 53 ARC (Application Recovery Controller) está disponible en todas las regiones, pero el plano de control de ARC Routing Controls opera globalmente. Para este workshop usaremos us-east-1 (N. Virginia) como región principal, ya que es donde ARC tiene soporte completo y donde los Health Checks de Route 53 son globales.</description>
    </item>
    <item>
      <title>Lab 1: Sitio Web Primario</title>
      <link>https://aws-route53-labs.rofriday.com/01_sitio_primario/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://aws-route53-labs.rofriday.com/01_sitio_primario/index.html</guid>
      <description>Lab 1: Sitio Web Primario (EC2 + ALB) En este lab desplegaremos el sitio web principal usando EC2 con nginx y un Application Load Balancer.&#xA;¿Qué vamos a crear? Internet → Route 53 → ALB (puerto 80) → EC2 Amazon Linux 2023 + nginx EC2 con Amazon Linux 2023 (ARM) + nginx sirviendo HTML estático ALB como punto de entrada con health check propio VPC (default existente o nueva, a tu elección) Security Groups para el ALB y EC2 Instancia recomendada Tipo Arquitectura vCPU RAM Free Tier t4g.micro ⭐ ARM (Graviton2) 2 1 GB ✅ primeros 12 meses t3.micro x86_64 2 1 GB ✅ primeros 12 meses Usamos t4g.micro por defecto — mismo precio que t3.micro pero hasta 40% más eficiente. Si por alguna razón no está disponible en tu región o preferís x86, el parámetro del template te permite elegir.</description>
    </item>
    <item>
      <title>Lab 2: Sitio Secundario (Fallback)</title>
      <link>https://aws-route53-labs.rofriday.com/02_sitio_secundario/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://aws-route53-labs.rofriday.com/02_sitio_secundario/index.html</guid>
      <description>Lab 2: Sitio Secundario – S3 + CloudFront En este lab creamos la página de fallback: lo que verán los usuarios cuando el sitio primario no esté disponible. Es una página estática muy simple alojada en S3 y distribuida por CloudFront.&#xA;¿Qué vamos a crear? Internet → CloudFront → S3 (estático) S3 Bucket con acceso solo desde CloudFront (OAC) CloudFront Distribution con HTTPS automático Página HTML estilo “mantenimiento” con branding ¿Por qué S3 + CloudFront? Ventaja Detalle Costo casi cero S3 cobra centavos por GB; CloudFront tiene free tier Alta disponibilidad CloudFront tiene SLA de 99.99% Sin servidores Completamente serverless, no hay nada que “caer” HTTPS gratis CloudFront incluye certificado SSL automático Paso 1: Variables de entorno export AWS_REGION=&#34;us-east-1&#34; export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export STACK_NAME_SECONDARY=&#34;route53-arc-secondary&#34; export BUCKET_NAME=&#34;route53-arc-fallback-${AWS_ACCOUNT_ID}&#34; echo &#34;Bucket name: $BUCKET_NAME&#34; Paso 2: Crear el template CloudFormation cat &gt; /tmp/secondary-site.yaml &lt;&lt; &#39;TEMPLATE_EOF&#39; AWSTemplateFormatVersion: &#39;2010-09-09&#39; Description: &#39;roLearning - Route53 ARC Workshop - Sitio Secundario (S3 + CloudFront)&#39; Parameters: BucketName: Type: String Description: &#34;Nombre único para el bucket S3&#34; Resources: # ────────────────────────────────────────────── # S3 Bucket para el sitio estático # ────────────────────────────────────────────── FallbackBucket: Type: AWS::S3::Bucket Properties: BucketName: !Ref BucketName PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true Tags: - Key: Workshop Value: route53-arc - Key: Site Value: secondary # ────────────────────────────────────────────── # Origin Access Control para CloudFront # ────────────────────────────────────────────── CloudFrontOAC: Type: AWS::CloudFront::OriginAccessControl Properties: OriginAccessControlConfig: Name: route53-arc-fallback-oac OriginAccessControlOriginType: s3 SigningBehavior: always SigningProtocol: sigv4 # ────────────────────────────────────────────── # Bucket Policy - permite acceso solo desde CloudFront # ────────────────────────────────────────────── FallbackBucketPolicy: Type: AWS::S3::BucketPolicy Properties: Bucket: !Ref FallbackBucket PolicyDocument: Statement: - Sid: AllowCloudFrontServicePrincipal Effect: Allow Principal: Service: cloudfront.amazonaws.com Action: s3:GetObject Resource: !Sub &#34;${FallbackBucket.Arn}/*&#34; Condition: StringEquals: &#34;AWS:SourceArn&#34;: !Sub &#34;arn:aws:cloudfront::${AWS::AccountId}:distribution/${FallbackDistribution}&#34; # ────────────────────────────────────────────── # CloudFront Distribution # ────────────────────────────────────────────── FallbackDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Enabled: true DefaultRootObject: index.html Comment: &#34;roLearning - Route53 ARC Fallback Site&#34; HttpVersion: http2 Origins: - Id: S3FallbackOrigin DomainName: !GetAtt FallbackBucket.RegionalDomainName OriginAccessControlId: !Ref CloudFrontOAC S3OriginConfig: OriginAccessIdentity: &#34;&#34; DefaultCacheBehavior: ViewerProtocolPolicy: redirect-to-https TargetOriginId: S3FallbackOrigin CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6 # CachingOptimized AllowedMethods: [GET, HEAD] CachedMethods: [GET, HEAD] CustomErrorResponses: - ErrorCode: 403 ResponseCode: 200 ResponsePagePath: /index.html - ErrorCode: 404 ResponseCode: 200 ResponsePagePath: /index.html Tags: - Key: Workshop Value: route53-arc - Key: Site Value: secondary Outputs: FallbackBucketName: Description: &#34;Nombre del bucket S3&#34; Value: !Ref FallbackBucket Export: Name: route53-arc-fallback-bucket CloudFrontDomain: Description: &#34;Dominio de la distribución CloudFront&#34; Value: !GetAtt FallbackDistribution.DomainName Export: Name: route53-arc-cf-domain CloudFrontDistributionId: Description: &#34;ID de la distribución CloudFront&#34; Value: !Ref FallbackDistribution Export: Name: route53-arc-cf-distribution-id TEMPLATE_EOF echo &#34;✅ Template creado: $(wc -l &lt; /tmp/secondary-site.yaml) líneas&#34; Paso 3: Desplegar el stack secundario aws cloudformation deploy \ --template-file /tmp/secondary-site.yaml \ --stack-name $STACK_NAME_SECONDARY \ --capabilities CAPABILITY_IAM \ --region $AWS_REGION \ --parameter-overrides BucketName=$BUCKET_NAME \ --tags Workshop=route53-arc Environment=secondary echo &#34;Desplegando sitio secundario...&#34; Información CloudFront puede tardar 5-10 minutos en desplegarse completamente. El stack dirá CREATE_COMPLETE antes de que CloudFront esté 100% activo. Esto es normal.</description>
    </item>
    <item>
      <title>Lab 3: Route 53 Health Checks &#43; ARC</title>
      <link>https://aws-route53-labs.rofriday.com/03_route53_arc/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://aws-route53-labs.rofriday.com/03_route53_arc/index.html</guid>
      <description>Lab 3: Route 53 Health Checks + ARC Routing Controls El corazón del workshop. Configuramos la detección automática de caídas y el enrutamiento inteligente del tráfico.&#xA;Conceptos clave Route 53 Health Check Monitorea tu endpoint (el ALB) cada 30 segundos desde múltiples ubicaciones globales de AWS. Cuando detecta que el primario no responde, puede cambiar el DNS automáticamente.&#xA;Route 53 ARC – Application Recovery Controller Componente Función Cluster Plano de control global con alta disponibilidad Control Panel Agrupa los Routing Controls lógicamente Routing Control Interruptor on/off por sitio Safety Rule Garantiza que siempre haya al menos un sitio activo ARC Cluster └── Control Panel ├── Routing Control: &#34;primary&#34; ON = tráfico al primario └── Routing Control: &#34;secondary&#34; ON = tráfico al secundario └── Safety Rule: mínimo 1 siempre ON Paso 1: Variables base export AWS_REGION=&#34;us-east-1&#34; export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) # Recuperar outputs de labs anteriores export PRIMARY_ALB_DNS=$(aws cloudformation describe-stacks \ --stack-name route53-arc-primary --region $AWS_REGION \ --query &#39;Stacks[0].Outputs[?OutputKey==`ALBDNSName`].OutputValue&#39; \ --output text) export PRIMARY_ALB_HZ=$(aws cloudformation describe-stacks \ --stack-name route53-arc-primary --region $AWS_REGION \ --query &#39;Stacks[0].Outputs[?OutputKey==`ALBHostedZoneID`].OutputValue&#39; \ --output text) export CF_DOMAIN=$(aws cloudformation describe-stacks \ --stack-name route53-arc-secondary --region $AWS_REGION \ --query &#39;Stacks[0].Outputs[?OutputKey==`CloudFrontDomain`].OutputValue&#39; \ --output text) echo &#34;ALB DNS: $PRIMARY_ALB_DNS&#34; echo &#34;CF Domain: $CF_DOMAIN&#34; Paso 2: ¿Usás un dominio propio? (opcional) Tenés dos modos para este lab. Elegí el que corresponde a tu situación:</description>
    </item>
    <item>
      <title>Lab 4: Notificaciones SNS &#43; Lambda Failover</title>
      <link>https://aws-route53-labs.rofriday.com/04_notificaciones_sns/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://aws-route53-labs.rofriday.com/04_notificaciones_sns/index.html</guid>
      <description>Lab 4: Notificaciones SNS + Lambda Failover En este lab conectamos todos los piezas: cuando el Health Check detecta que el primario cae, SNS envía un email/SMS y Lambda ejecuta el failover cambiando el Routing Control automáticamente.&#xA;Flujo completo Health Check falla │ ▼ CloudWatch Alarm → &#34;ALARM&#34; │ ├──► SNS Topic → Email (notificación instantánea) │ → SMS (opcional) │ └──► Lambda Function &#34;failover-handler&#34; │ ├── Cambia Primary RC → OFF ├── Cambia Secondary RC → ON └── Publica confirmación en SNS Paso 1: Variables de entorno export AWS_REGION=&#34;us-east-1&#34; export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) # Recuperar ARNs del Lab 3 export PRIMARY_RC_ARN=$(aws cloudformation describe-stacks \ --stack-name route53-arc-routing --region $AWS_REGION \ --query &#39;Stacks[0].Outputs[?OutputKey==`PrimaryRoutingControlArn`].OutputValue&#39; \ --output text) export SECONDARY_RC_ARN=$(aws cloudformation describe-stacks \ --stack-name route53-arc-routing --region $AWS_REGION \ --query &#39;Stacks[0].Outputs[?OutputKey==`SecondaryRoutingControlArn`].OutputValue&#39; \ --output text) export ARC_CLUSTER_ARN=$(aws cloudformation describe-stacks \ --stack-name route53-arc-routing --region $AWS_REGION \ --query &#39;Stacks[0].Outputs[?OutputKey==`ARCClusterArn`].OutputValue&#39; \ --output text) export CW_ALARM_NAME=$(aws cloudformation describe-stacks \ --stack-name route53-arc-routing --region $AWS_REGION \ --query &#39;Stacks[0].Outputs[?OutputKey==`CloudWatchAlarmName`].OutputValue&#39; \ --output text) # IMPORTANTE: reemplaza con tu email real export NOTIFICATION_EMAIL=&#34;tu-email@ejemplo.com&#34; # OPCIONAL: reemplaza con tu número (formato internacional) export NOTIFICATION_PHONE=&#34;+54911XXXXXXXX&#34; echo &#34;Primary RC: $PRIMARY_RC_ARN&#34; echo &#34;Secondary RC: $SECONDARY_RC_ARN&#34; echo &#34;CW Alarm: $CW_ALARM_NAME&#34; Aviso Reemplaza tu-email@ejemplo.com con tu email real antes de continuar. Recibirás un email de confirmación de AWS SNS que debes aceptar para que las notificaciones lleguen.</description>
    </item>
    <item>
      <title>Lab 5: Simulación de Incidente</title>
      <link>https://aws-route53-labs.rofriday.com/05_automatizacion_lambda/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://aws-route53-labs.rofriday.com/05_automatizacion_lambda/index.html</guid>
      <description>Lab 5: Simulación de Incidente y Verificación del Failover ¡Llegó el momento de la verdad! Vamos a simular una caída del sitio primario y verificar que todo el flujo funciona: detección → notificación → failover automático.&#xA;El plan de la simulación Hay dos formas de simular la caída:&#xA;Método Descripción Velocidad A. Detener nginx Parar el servicio nginx en EC2 Health Check falla en ~2 min B. Forzar alarma CloudWatch Poner la alarma directamente en ALARM Inmediato Usaremos ambos: primero el método B para ver el flujo completo rápido, y luego el A para la experiencia “real”.</description>
    </item>
    <item>
      <title>Lab 6: Failback – Volver al Sitio Primario</title>
      <link>https://aws-route53-labs.rofriday.com/06_simulacion_incidente/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://aws-route53-labs.rofriday.com/06_simulacion_incidente/index.html</guid>
      <description>Lab 6: Failback – Restaurar el Tráfico al Sitio Primario El failover fue automático. El failback es siempre manual e intencional: primero reparamos el sitio primario, verificamos que funciona, y solo entonces devolvemos el tráfico.&#xA;¿Por qué el failback es manual? El failover automático protege la disponibilidad. El failback manual protege contra restauraciones prematuras: nadie quiere que el tráfico vuelva a un servidor que “cree” que está bien pero en realidad sigue fallando.</description>
    </item>
    <item>
      <title>Lab 7: Limpieza</title>
      <link>https://aws-route53-labs.rofriday.com/07_limpieza/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://aws-route53-labs.rofriday.com/07_limpieza/index.html</guid>
      <description>Lab 7: Limpieza de Recursos Elimina todos los recursos creados durante el workshop para evitar cargos en tu cuenta AWS.&#xA;Aviso Ejecuta este lab al finalizar el workshop. Los recursos de AWS generan costos mientras existen, incluso si no están en uso activo. El costo total del workshop es mínimo si limpias rápido, pero puede acumularse si lo dejas días.&#xA;Orden de eliminación Los stacks tienen dependencias entre sí (via exports). Deben eliminarse en este orden:</description>
    </item>
  </channel>
</rss>