En la lección anterior recorrimos la consola y creamos nuestro primer bucket con el ratón. Funcionó, pero dejamos una pregunta abierta: ¿cómo repites eso mismo cien veces, o cómo demuestras dentro de seis meses qué hiciste exactamente? La respuesta es dejar de hacer clic y empezar a escribir comandos y código.

Esta lección es la puerta de entrada a todo el trabajo serio en AWS. La AWS CLI es la herramienta que usarás a diario para consultar, crear y diagnosticar; los SDK son las bibliotecas con las que tu aplicación habla con AWS desde dentro. Ambos usan las mismas APIs que la consola, así que todo lo que aprendas aquí te sirve para cualquier servicio del resto del curso.

1. Por qué automatizar: el problema de la consola
2. Instalar AWS CLI v2 en Linux, macOS y Windows
3. Anatomía de un comando
4. Configurar credenciales: aws configure, ficheros y perfiles
5. Orden de precedencia de las credenciales
6. Seguridad de las claves de acceso
7. Formatos de salida y filtrado con --query
8. Paginación, --dry-run y otras opciones útiles
9. Comandos de exploración imprescindibles
10. SDKs: qué son y qué lenguajes hay
11. boto3: el SDK de Python paso a paso
12. Un vistazo equivalente en JavaScript
13. CloudShell como alternativa sin instalación

Marta creó el bucket de pruebas en la consola. Ahora Luis necesita crear tres buckets iguales (uno por entorno) con las mismas etiquetas y la misma configuración. Con la consola tendría que repetir unos quince clics tres veces, y cualquier despiste produciría una diferencia silenciosa entre entornos.

Los cuatro problemas estructurales de la consola:

La CLI resuelve los cuatro: un comando es texto, y el texto se guarda, se versiona, se revisa, se repite y se encadena. Y es el paso previo natural hacia la infraestructura como código del módulo 9, donde ya ni siquiera escribiremos comandos sino declaraciones del estado deseado.

Usa siempre la versión 2. La v1 está en mantenimiento, se instalaba con pip (lo que causaba conflictos de dependencias) y le faltan funciones importantes como el inicio de sesión con IAM Identity Center.

Qué hace cada línea:

• curl ... -o "awscliv2.zip": descarga el paquete y lo guarda con ese nombre. La URL es la oficial de AWS; desconfía de instaladores de terceros.
• unzip: extrae una carpeta aws/ con el instalador.
• sudo ./aws/install: copia los binarios a /usr/local/aws-cli y crea el enlace /usr/local/bin/aws. Necesita sudo porque escribe fuera de tu directorio personal.
• rm -rf: borra lo descargado, que ya no hace falta.

Si tu máquina es ARM (por ejemplo, una instancia Graviton), cambia x86_64 por aarch64.

Para actualizar una instalación existente, añade los parámetros de actualización:

Alternativa con Homebrew, si ya lo usas: brew install awscli.

Descarga y ejecuta el instalador MSI oficial:

O desde PowerShell como administrador:

Después cierra y abre de nuevo la terminal para que se recargue la variable PATH.

En cualquier sistema:

Salida esperada (los números variarán):

Se lee así: versión de la CLI, versión de Python embebida (no usa tu Python, va incluida), sistema operativo y tipo de compilación. Si ves aws-cli/1.x, tienes la v1 y deberías desinstalarla antes de continuar.

Todos los comandos siguen la misma estructura:

Un ejemplo real, línea a línea:

Los verbos siguen convenciones muy predecibles, y reconocerlas acelera mucho el aprendizaje:

Es la mejor documentación que tienes y funciona sin conexión:

Se abre en un paginador: navega con las flechas y sal con q.

La CLI necesita saber quién eres. Vamos a crear unas claves de acceso para el usuario mercadofresco-admin que creamos en la lección 01-02.

En la consola: IAM → Users → mercadofresco-admin → Security credentials → Create access key. Elige el caso de uso Command Line Interface (CLI), confirma el aviso y crea.

Obtendrás dos valores:

• Access key ID: algo como AKIAIOSFODNN7EXAMPLE. Es público-ish, identifica la clave.
• Secret access key: algo como wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY. Solo se muestra una vez. Si la pierdes, hay que crear una clave nueva.

Advertencia: nunca crees claves de acceso para el usuario root (lección 01-02). Y si no quieres manejar claves permanentes en absoluto, la alternativa moderna es aws configure sso con IAM Identity Center, que emite credenciales temporales.

Te hará cuatro preguntas:

• Región por defecto: eu-west-1, la que decidimos en la lección 01-03. Te evita escribir --region en cada comando.
• Formato de salida: json es un buen valor por defecto porque es el que consumen otras herramientas.

aws configure no hace magia: escribe dos ficheros de texto en tu directorio personal (~/.aws/ en Linux y macOS, %USERPROFILE%\.aws\ en Windows).

~/.aws/credentials — contiene los secretos:

~/.aws/config — contiene los ajustes no secretos:

Puedes editarlos a mano perfectamente. Comprueba además que los permisos sean restrictivos:

Esto deja el fichero legible y escribible solo por tu usuario. En un equipo compartido es imprescindible.

Casi nunca trabajarás con una sola identidad. MercadoFresco tendrá pronto un entorno de desarrollo y otro de producción, y conviene que no se puedan confundir.

Crea un perfil nuevo:

Los ficheros quedan así:

Atención al detalle: en credentials la sección es [mercadofresco-dev], pero en config es [profile mercadofresco-dev], con la palabra profile delante. Es una inconsistencia histórica que provoca errores constantes. Si un perfil "no se encuentra", revisa esto primero.

Para usar un perfil:

Y para saber siempre con quién estás actuando:

Adquiere el hábito de ejecutar este comando antes de cualquier operación destructiva. Es la diferencia entre borrar la base de datos de desarrollo y borrar la de producción.

Cuando ejecutas un comando, la CLI busca credenciales en un orden fijo y se queda con la primera fuente que encuentre. Conocer este orden explica el 90 % de los "pero si yo configuré eso":

Los dos últimos son los importantes conceptualmente. Cuando tu código se ejecuta dentro de AWS —en una instancia EC2, en una función Lambda, en un contenedor— no necesita claves en absoluto: se le asigna un rol IAM y el SDK obtiene automáticamente credenciales temporales que se rotan solas cada pocas horas.

Los roles IAM se estudian a fondo en la lección 04-01. Quédate con la idea: claves permanentes solo en tu portátil; dentro de AWS, siempre roles.

Una clave de acceso de mercadofresco-admin es, literalmente, el control total de la cuenta. Estas reglas no son opcionales.

Este es el error que arruina cuentas todos los días. Hay bots que escanean GitHub de forma continua buscando cadenas que empiecen por AKIA; una clave publicada se explota en minutos, típicamente lanzando decenas de instancias grandes para minar criptomonedas. La factura resultante puede ser de miles de euros.

Protección mínima en cualquier repositorio:

Y una barrera automática, muy recomendable:

Si alguna vez publicas una clave por error: desactívala y bórrala inmediatamente en IAM, revisa CloudTrail (lección 05-03) para ver qué se hizo con ella, y crea una nueva. Borrar el commit no sirve de nada: ya está indexado.

El procedimiento de rotación sin cortes es sencillo: crea una segunda clave, actualiza donde se use, comprueba que todo funciona, desactiva la antigua, espera unos días y bórrala. IAM permite dos claves activas por usuario precisamente para esto.

Los comandos de AWS devuelven mucha información. Aprender a recortarla es lo que convierte la CLI en una herramienta cómoda.

--query aplica una expresión JMESPath sobre la respuesta, en el cliente. Vamos de menos a más.

Nivel 1 — extraer una lista:

Nivel 2 — un campo de cada elemento:

Salida:

Nivel 3 — renombrar campos en un objeto:

Las llaves {...} construyen un objeto nuevo; a la izquierda del : va el nombre que quieres ver, a la derecha el campo original.

Nivel 4 — filtrar con una condición:

Fíjate en las comillas invertidas alrededor de eu-: en JMESPath, los literales van entre backticks, no entre comillas normales. Es una fuente frecuente de errores.

Nivel 5 — un caso real de MercadoFresco:

Desglose:

• Reservations[].Instances[]: aplana la estructura anidada de EC2 (las instancias vienen agrupadas por reserva) en una sola lista.
• State.Name: navega dentro de un objeto anidado con el punto.
• Tags[?Key==\Name`]|[0].Value: filtra las etiquetas quedándose con la de clave Name, y el |[0]` toma el primer resultado de esa lista para extraer su valor.

Lo ideal es combinarlos: --filters para traer poco, --query para presentarlo bien.

Cuando hay muchos resultados, la CLI v2 los pagina automáticamente y abre un paginador. Opciones para controlarlo:

Si limitas con --max-items y hay más resultados, la respuesta incluye un NextToken que puedes pasar con --starting-token para pedir la página siguiente.

Muchas operaciones de EC2 aceptan --dry-run: comprueban si tendrías permisos para hacer la operación, pero no la ejecutan.

Si tienes permiso, verás:

Ese mensaje, aunque diga "error", es la confirmación de éxito. Si no tuvieras permiso, el error sería UnauthorizedOperation. Es una forma segura de verificar permisos sin crear nada ni gastar nada.

Estos son los comandos que ejecutarás cientos de veces. Guárdalos.

La salida del último es especialmente útil porque indica el origen de cada valor:

Cuando algo no funcione como esperas, este comando te dirá exactamente qué credencial y qué región está usando la CLI y por qué.

Un SDK (Software Development Kit) es una biblioteca que permite a tu aplicación llamar a las APIs de AWS desde el lenguaje en el que está escrita, sin construir peticiones HTTP firmadas a mano.

La diferencia con la CLI:

Lenguajes con SDK oficial:

Todos comparten la misma lógica: cadena de proveedores de credenciales (el mismo orden de precedencia que vimos), reintentos automáticos con retroceso exponencial, y nombres de operación equivalentes a los de la API.

Luis va a usar Python para los scripts de MercadoFresco, así que veamos boto3 en detalle.

boto3 ofrece dos interfaces distintas para lo mismo:

Ejemplo del mismo objetivo con ambos:

boto3 usa exactamente el mismo orden de precedencia que la CLI, así que si aws s3 ls funciona, tu código Python funcionará sin configurar nada.

Para elegir perfil o región explícitamente se usa una sesión:

Todo error devuelto por un servicio de AWS llega como botocore.exceptions.ClientError. Ignorarlo es el error más común de los scripts de principiante.

Puntos clave del fragmento:

• head_bucket es la forma barata de comprobar existencia: no descarga contenido.
• error.response["Error"]["Code"] es la ruta estándar para leer el código de error. Memorízala.
• Distinguir 404 de 403 importa: "no existe" y "existe pero no puedes verlo" exigen acciones distintas.
• El raise final evita el antipatrón de tragarse errores desconocidos, que oculta problemas reales.

Las APIs devuelven como mucho unos cientos de elementos por llamada. Si iteras solo la primera respuesta, perderás datos en silencio. Los paginadores lo resuelven:

Para que veas que los conceptos se trasladan, el mismo listado de buckets con el AWS SDK for JavaScript v3:

Diferencias respecto a boto3: el v3 es modular (menos peso en Lambda) y usa el patrón comando: creas un objeto XxxCommand y lo envías con send(). La lógica de credenciales, reintentos y errores es equivalente.

Como vimos en la lección 01-04, AWS CloudShell te da una terminal en el navegador con la CLI v2, Python y boto3 ya instalados, y autenticada automáticamente con el usuario de la consola.

CloudShell es especialmente útil para el escenario "estoy en un ordenador que no es el mío y necesito diagnosticar algo ya". No sustituye a la CLI local para el trabajo diario, pero es una red de seguridad excelente.

• Unable to locate credentials. No has configurado el perfil, o has usado un nombre de perfil inexistente. Diagnostica con aws configure list.
• ProfileNotFound con el perfil bien escrito. Casi siempre es la sección de ~/.aws/config sin el prefijo profile : debe ser [profile mercadofresco-dev], no [mercadofresco-dev].
• You must specify a region. Ni el perfil ni la variable de entorno ni el comando indican región. Añade --region o configúrala en el perfil.
• AccessDenied inesperado. Comprueba primero con qué identidad estás actuando con aws sts get-caller-identity; muy a menudo es el perfil equivocado, no un problema de permisos.
• Subir claves a Git. El desastre más caro y más frecuente. .gitignore, git secrets y, mejor aún, credenciales temporales.
• Usar claves permanentes dentro de una instancia EC2. Nunca. Se usa un rol de instancia (lección 04-01), que además rota las credenciales solo.
• Olvidar la paginación. Tu script dice "hay 1.000 objetos" cuando hay 50.000. Usa paginadores en boto3 y --max-items/NextToken en la CLI.
• Confundir aws s3 con aws s3api. El primero es de alto nivel (ls, cp, sync); el segundo expone la API completa (get-bucket-tagging, put-bucket-policy). Si una opción no existe en s3, búscala en s3api.
• Ignorar ClientError. Un script que falla en silencio es peor que uno que se rompe.
• Consejo: define alias en tu terminal para lo que repitas mucho, por ejemplo alias quien='aws sts get-caller-identity'.
• Consejo: cuando un comando no funcione y no entiendas por qué, añade --debug. Verás la petición firmada completa y la respuesta del servicio.

1. Instala AWS CLI v2 en tu sistema y verifica la versión.
2. Configura un perfil llamado mercadofresco-admin con región eu-west-1 y salida json.
3. Ejecuta aws sts get-caller-identity y anota tu ARN completo.
4. Escribe un solo comando que muestre, en formato tabla, todas las regiones cuyo nombre empiece por eu-, con una única columna llamada Region.

Escribe un script inventario-mercadofresco.sh que:

1. Compruebe con qué identidad y en qué cuenta se está ejecutando, y lo muestre.
2. Liste todos los buckets de S3 de la cuenta.
3. Liste las zonas de disponibilidad de eu-west-1 con su ID físico.
4. Liste las instancias EC2 con su ID, tipo, estado y zona (si no hay ninguna, debe indicarlo sin fallar).
5. Todo con salida en tabla y sin abrir el paginador interactivo.

Escribe un script Python crear_bucket_mercadofresco.py que:

1. Reciba el nombre del bucket como argumento de línea de comandos.
2. Compruebe si ya existe (distinguiendo "no existe" de "sin permisos").
3. Si no existe, lo cree en eu-west-1 con el bloqueo de acceso público activado.
4. Le aplique las etiquetas Proyecto=mercadofresco, Entorno=pruebas, Componente=formacion.
5. Muestre las etiquetas resultantes.
6. Maneje los errores con ClientError y devuelva un código de salida distinto de cero si falla.

Coste: un bucket vacío no genera coste apreciable y la capa gratuita cubre 5 GB. Aun así, bórralo al terminar con aws s3 rb s3://<nombre-del-bucket>.

Solución 1

Se puede usar starts_with() o contains(); starts_with es más preciso porque contains también aceptaría un nombre que llevara eu- en el medio.

Solución 2

Detalles importantes:

• set -euo pipefail evita que el script continúe alegremente tras un fallo.
• export AWS_PAGER="" es imprescindible en scripts: sin ello, la CLI abriría un paginador y el script se quedaría bloqueado esperando a que alguien pulse q.
• Guardar la salida en una variable permite comprobar si está vacía y dar un mensaje claro en lugar de imprimir una tabla vacía.

Se ejecuta con:

Solución 3

Claves de la solución:

• LocationConstraint: si creas un bucket en cualquier región que no sea us-east-1 y omites este parámetro, S3 lo crea en us-east-1. Es una de las rarezas históricas de la API.
• put_public_access_block con las cuatro opciones a True es la protección que evita la fuga de datos más habitual en AWS.
• put_bucket_tagging sobrescribe el conjunto completo de etiquetas: si quisieras añadir una sin borrar las demás, tendrías que leerlas primero con get_bucket_tagging y fusionarlas.
• Códigos de salida: 0 si todo va bien, 1 si falla, para poder encadenar el script en un pipeline.

Ejecución y limpieza:

Con esta lección cierras el módulo de introducción y, sobre todo, das el salto de "usuario de AWS" a "operador de AWS". Has instalado la AWS CLI v2, has entendido la anatomía de un comando (aws <servicio> <operación> --parámetros) y las convenciones de nombres que te permiten adivinar comandos que aún no conoces. Has configurado credenciales con aws configure, has visto qué hay realmente dentro de ~/.aws/credentials y ~/.aws/config, y sabes trabajar con perfiles nombrados para no confundir jamás desarrollo con producción. Conoces el orden de precedencia de las credenciales, que explica casi todos los comportamientos extraños, y las reglas de seguridad innegociables: nunca claves en Git, rotación periódica y, dentro de AWS, roles en lugar de claves.

Has aprendido a domar la salida de los comandos con --output y con --query y JMESPath, a evitar la trampa silenciosa de la paginación, a verificar permisos sin gastar nada con --dry-run, y tienes en la mano el puñado de comandos de exploración que usarás cada día. Y has dado tus primeros pasos con los SDK: boto3 en Python, con la distinción entre client y resource, el manejo correcto de errores mediante ClientError y los paginadores, más el equivalente en JavaScript para ver que los conceptos son universales.

MercadoFresco ya tiene todo lo necesario para empezar de verdad: una cuenta segura y vigilada, una región elegida con criterio, una consola que sabes manejar y unas herramientas de línea de comandos y programación que hacen el trabajo repetible.

En el módulo 2, «Servicios principales de AWS», empezando por la lección 02-01 «Amazon EC2», levantaremos el primer servidor real de MercadoFresco en la nube y comenzaremos la migración que resolverá, uno a uno, los cuatro problemas que descubrimos en la primera lección.