Consola, CLI y SDK: una API con tres puertas
Crear un recurso con clics, comandos o código termina en la misma API. La diferencia es cuánto podés revisar, repetir, automatizar y auditar sin depender de memoria humana.
Para este tema conviene tener claro:Usuarios, grupos, roles y mínimo privilegio
Datos de proveedores verificados contra la documentación oficial el 15 de sept de 2026.
Hacés clic en «Crear bucket» y parece que la consola fabricó algo. No: armó un pedido HTTP, lo autenticó y llamó a una API. La CLI hace lo mismo desde una terminal y el SDK desde tu programa. El recurso no sabe por qué puerta entró el pedido.
Tres clientes de la misma API
La consola optimiza descubrimiento: muestra opciones, ayuda contextual y una vista rápida del estado. La CLI optimiza repetición: un comando se guarda, se revisa y se ejecuta otra vez. El SDK optimiza integración: la aplicación llama al servicio como parte de su propia lógica.
| Camino | Conviene para | Fortaleza | Riesgo |
|---|---|---|---|
| Consola web | Explorar y diagnosticar | Hace visible el catálogo y el estado | Cambios manuales difíciles de reproducir |
| CLI | Operación y scripts acotados | Comandos repetibles y salida estructurada | Un script sin controles puede repetir un daño rápido |
| SDK | Aplicaciones y automatización mantenida | Tipos, reintentos y manejo de errores | Acoplar lógica de negocio al proveedor |
| IaC | Infraestructura declarativa | Plan, revisión y estado compartido | Un estado mal protegido expone o bloquea toda la plataforma |
Primero: saber quién sos y dónde estás
Antes de listar o crear recursos, verificá la identidad y el ámbito activos. Es el equivalente a mirar el destinatario antes de enviar un mensaje: evita correr un comando correcto en la cuenta equivocada.
# AWS: identidad y cuenta efectivas
aws sts get-caller-identity
# Google Cloud: cuenta y proyecto activos
gcloud auth list --filter=status:ACTIVE
gcloud config get-value project
# Azure: usuario, tenant y suscripción activos
az account show --query '{subscription:name, tenant:tenantId, user:user.name}'AWS documenta credenciales temporales e IAM Identity Center como opciones recomendadas para la
autenticación de la CLI.
Google separa el login de gcloud de las credenciales que usan las librerías mediante
Application Default Credentials.
Azure distingue el acceso interactivo, las identidades administradas y los principales de servicio
en su guía de autenticación.
Inventario de sólo lectura en Cloud Shell
Los tres proveedores ofrecen una terminal en el navegador con su CLI instalada. Elegí la nube a la que tengas acceso y hacé un inventario que no modifica recursos.
AWS CloudShell y Azure Cloud Shell entran autenticados desde la sesión del navegador; Google Cloud Shell también arranca con las herramientas del SDK configuradas para el proyecto elegido. Esa comodidad es para uso humano, no una credencial para copiar a un servidor.
El SDK vive dentro de la aplicación
Una CLI traduce argumentos a una llamada. Un SDK agrega objetos del lenguaje, serialización, autenticación, reintentos y errores propios del servicio. El patrón general es siempre parecido:
const client = new StorageServiceClient();
const result = await client.listObjects({ container: 'reportes' });El ejemplo omite a propósito una clave. Los SDK buscan credenciales mediante una cadena de
proveedores: identidad de la carga cuando corre en la nube, federación para CI, perfiles para
desarrollo local y variables de entorno en casos acotados. AWS documenta el orden en su
referencia de configuración;
Google llama al patrón Application Default Credentials y Azure usa DefaultAzureCredential.
De comando exploratorio a cambio repetible
Un buen recorrido tiene cuatro escalones:
Cómo madura un cambio
- Exploralo en la consola para entender opciones y dependencias.
- Repetilo con la CLI y pedí salida JSON para comprobar el resultado sin leer texto decorativo.
- Si forma parte de la infraestructura, expresalo en Terraform o en la herramienta declarativa del proveedor; revisá el plan antes de aplicar.
- Si forma parte del comportamiento de la aplicación, usá el SDK detrás de una función chica que traduzca errores y no contamine toda la lógica de negocio con tipos del proveedor.
Antes de seguir, predecí
Automatizar también automatiza errores
Antes de ejecutar un script que escribe:
- fijá explícitamente cuenta, proyecto, suscripción y región;
- empezá con comandos de lectura y validá que la selección no esté vacía ni sea más grande de lo esperado;
- preferí operaciones idempotentes: correr dos veces debería dejar el mismo estado;
- registrá quién ejecutó, qué versión del script y sobre qué ámbito;
- pedí aprobación para producción y separá los permisos de lectura de los de escritura.
Lo que preguntan sobre esto
Cierre
Autoevaluación
¿Lo entendiste?
Práctica