Problema

En entornos productivos basados en AWS es frecuente que una cuenta sea marcada como “suspended” bajo la razón non‑payment aunque el balance aparezca en cero. La suspensión bloquea el acceso a todos los recursos: clústers de EKS, bases de datos RDS, volúmenes EBS, colas de SQS, etc. El resultado inmediato es la caída total del servicio y la imposibilidad de usar credenciales IAM para exportar datos o ejecutar comandos. El problema se vuelve crítico cuando la suspensión ocurre justo antes de un lanzamiento o durante la facturación mensual, generando presión sobre equipos de negocio y clientes.

Causa

Las causas más habituales que desencadenan este tipo de suspensión son:

  1. Cambio de método de pago sin sincronizar
    Reemplazar la tarjeta registrada mientras hay una factura pendiente puede dejar la cuenta en estado “pending verification”. AWS procesa el pago, pero el flag de verificación no se elimina automáticamente.

  2. Alertas de fraude o verificación de identidad
    Cuando la información de la tarjeta proviene de un tercero (proveedor externo, agencia, etc.) los sistemas anti‑fraude pueden marcar la cuenta. La revisión manual a veces se pierde entre casos abiertos.

  3. Incumplimiento de cuotas o políticas de servicio
    Solicitudes de aumento de vCPU, habilitación de SES en producción o cambios en CloudFront que quedan en “verification required” pueden activar un bloqueo preventivo.

  4. Desalineación entre Billing y Service Control Policies (SCP)
    En organizaciones con AWS Organizations, una política que impida el uso de ciertos servicios puede combinarse con un problema de pago y forzar la suspensión total.

  5. Errores internos de AWS
    En algunos casos, la actualización del estado de facturación no se refleja en el panel de Billing, pero el backend sigue considerando la cuenta como morosa.

Solución

Una estrategia de respuesta rápida se divide en tres capas: verificación de facturación, contacto con soporte especializado y mitigación de recursos críticos.

1. Verificar el estado de facturación mediante la CLI

Utilizar la AWS CLI permite obtener una visión sin depender del UI potencialmente bloqueado.

aws ce get-cost-and-usage \
  --time-period Start=$(date -d '-30 days' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
  --granularity MONTHLY \
  --metrics UnblendedCost

Si el resultado muestra 0.00 para el período actual, el pago está registrado. En caso contrario, captura el InvoiceId y el PaymentMethod para adjuntarlos al caso.

2. Escalar a un equipo de “Program Support”

Los tickets genéricos de Support a menudo se pierden. Crea un caso nuevo con los siguientes pasos:

  • Selecciona “Account and Billing” → “Account suspension”.
  • En la descripción, incluye:
    • ID de la cuenta y número de factura.
    • Evidencia de pago (captura de pantalla del portal de Billing o PDF del comprobante bancario).
    • Historial de cambios de método de pago (fecha, tarjetas involucradas).
    • Lista de recursos críticos (EKS, RDS, EBS) y su impacto comercial.
  • Marca la opción “Urgent – Production impact” y solicita la asignación a un Program Support Engineer.

Si el caso se cierra como duplicado, abre uno nuevo con referencia al número anterior y agrega la frase “Escalation required – previous case ID: XXXXXX”. AWS suele responder a la primera solicitud que incluye la palabra “Escalation”.

3. Proteger los datos mientras se resuelve la suspensión

Aunque la cuenta esté bloqueada, algunos recursos siguen accesibles mediante roles de servicio que no requieren credenciales de usuario. Ejecuta los siguientes comandos para crear un snapshot de los volúmenes EBS y exportar bases de datos RDS antes de que el control plane se apague:

# Crear snapshots de todos los volúmenes EBS en la región
for vol in $(aws ec2 describe-volumes --query "Volumes[*].VolumeId" --output text); do
  aws ec2 create-snapshot --volume-id $vol --description "Pre‑suspension snapshot $(date +%F)"
done

# Exportar RDS a un bucket S3 (requiere role con permisos rds:StartExportTask)
aws rds start-export-task \
  --export-task-identifier pre-suspension-$(date +%s) \
  --source-arn arn:aws:rds:us-east-1:123456789012:db:mydb \
  --s3-bucket-name my-backup-bucket \
  --iam-role-arn arn:aws:iam::123456789012:role/RDSExportRole

Si la cuenta ya impide la ejecución de CLI, solicita al soporte que habilite temporalmente un IAM role de emergencia con permisos ec2:CreateSnapshot y rds:StartExportTask.

4. Restaurar el control plane de EKS

Una vez que la suspensión se levante, el clúster puede quedar en estado IMPAIRED. El remedio típico es volver a asumir el service‑linked role y validar la clave KMS:

aws eks update-cluster-config \
  --name my-prod-cluster \
  --resources-vpc-config endpointPublicAccess=true

Si la clave KMS está marcada como inaccesible, verifica la política de la clave y re‑asigna el rol:

aws kms enable-key-rotation --key-id alias/eks-cluster-key
aws kms put-key-policy \
  --key-id alias/eks-cluster-key \
  --policy-name default \
  --policy file://policy.json

Reinicia los nodos del clúster para que vuelvan a registrar el role.

Cuándo aplicar esta solución

  • Síntomas: mensaje de suspensión por “non‑payment”, API endpoints que retornan InvalidClientTokenId, EKS marcado como IMPAIRED, CloudFront con 403 “verification required”.
  • Entorno: cualquier cuenta AWS con recursos críticos en producción (EKS, RDS, EBS, S3) y con facturación reciente.
  • No aplica: cuando la cuenta está cerrada permanentemente por incumplimiento de TOS o cuando la suspensión es por actividades ilegales (por ejemplo, abuso de recursos). En esos casos la única vía es apelar a través del proceso de “Account Closure Review”.

Código

# Verificar saldo de facturación
aws ce get-cost-and-usage \
  --time-period Start=$(date -d '-30 days' +%Y-%m-%d),End=$(date +%Y-%m-%d) \
  --granularity MONTHLY \
  --metrics UnblendedCost

# Crear snapshots de todos los volúmenes EBS
for vol in $(aws ec2 describe-volumes --query "Volumes[*].VolumeId" --output text); do
  aws ec2 create-snapshot --volume-id $vol --description "Pre‑suspension snapshot $(date +%F)"
done

# Exportar RDS a S3
aws rds start-export-task \
  --export-task-identifier pre-suspension-$(date +%s) \
  --source-arn arn:aws:rds:us-east-1:123456789012:db:mydb \
  --s3-bucket-name my-backup-bucket \
  --iam-role-arn arn:aws:iam::123456789012:role/RDSExportRole

Verificación

  1. Facturación: el comando aws ce get-cost-and-usage debe devolver 0.00 para el mes actual.
  2. Estado de la cuenta: en la consola de AWS Billing la barra de “Account status” debe mostrar Active.
  3. Recursos críticos: ejecuta aws eks describe-cluster --name my-prod-cluster y verifica que status sea ACTIVE.
  4. Snapshots y export: lista los snapshots con aws ec2 describe-snapshots --owner-ids self y confirma que la tarea de exportación de RDS aparece con Status: COMPLETED en aws rds describe-export-tasks.
  5. Conectividad: prueba los endpoints de la API (curl -I https://api.example.com/health) y asegúrate de recibir 200 OK.

Notas adicionales

  • Mantén una tarjeta de respaldo: en organizaciones que delegan la facturación, registra al menos dos métodos de pago válidos. AWS solo necesita que uno esté activo para evitar bloqueos.
  • Documenta cada cambio de pago: guarda la fecha, número de autorización y captura del portal. Facilita la escalación cuando el soporte solicite pruebas.
  • Automatiza alertas de facturación: configura CloudWatch Alarms en el metric EstimatedCharges para que te notifiquen antes de que la cuenta alcance un umbral de riesgo.
  • Política de retención de snapshots: conserva al menos 7 días de snapshots antes de cualquier cambio de pago; así tendrás margen para restaurar sin depender del estado de la cuenta.
  • Comunicación interna: designa a un “owner” de la cuenta que sea responsable de la facturación y tenga permisos billing:*. Evita que varios equipos cambien la tarjeta sin registro.

Con este enfoque, puedes reducir drásticamente el tiempo de inactividad causado por suspensiones inesperadas y garantizar que los datos críticos permanezcan seguros mientras AWS revisa el caso.