Cuando uno está aprendiendo AWS o creando una aplicación que usa servicios de la nube, muchas veces pensamos que hay que ir directo a una cuenta real de AWS para probar cualquier cosa.

Crear un bucket.
Crear una cola.
Configurar permisos.
Probar el comando.
Borrar recursos después.

Y aunque eso funciona, no siempre es lo más práctico.

Porque si estás aprendiendo, haciendo una demo o probando una idea rápida, no necesariamente quieres depender de una cuenta real, permisos reales y recursos que después se te pueden olvidar prendidos.

Ahí es donde entra Floci.

Floci te permite probar servicios parecidos a los de AWS desde tu máquina local. En vez de mandar los comandos directamente a AWS, los mandas a un endpoint local y puedes practicar sin crear infraestructura real en la nube desde el principio.

La idea no es reemplazar AWS.

La idea es tener un espacio seguro para practicar, romper cosas, repetir comandos y entender cómo funciona el flujo antes de llevarlo a un ambiente real.

Para este ejemplo vamos a enfocarnos en dos servicios:

S3 para almacenamiento de archivos
SQS para colas de mensajes

¿Por qué probar localmente?

Porque no todo tiene que empezar en la nube real.

A veces tú solo quieres validar algo simple:

¿Puedo subir un archivo?
¿Puedo listar lo que subí?
¿Puedo mandar un mensaje a una cola?
¿Puedo leer ese mensaje después?

Para ese tipo de prueba, usar un ambiente local tiene mucho sentido.

Primero pruebas la lógica.
Después validas en AWS real.
Y luego automatizas o despliegas con más confianza.

Levantando Floci localmente

Una forma sencilla de trabajar con Floci es usando Docker.

Puedes levantarlo con un comando como este:

docker run --rm -p 4566:4566 floci/floci:latest

Ese comando expone Floci localmente en el puerto 4566.

Luego, cuando uses AWS CLI, en vez de apuntar a AWS real, usas este endpoint:

--endpoint-url=http://localhost:4566

En otras palabras, le estás diciendo al comando:

No vayas a AWS real.
Usa mi ambiente local.

Y con eso ya puedes empezar a probar.

Probando S3 localmente

Amazon S3 es uno de los servicios más usados de AWS.

Se utiliza para guardar archivos como imágenes, documentos, reportes, backups.

Con Floci puedes simular ese flujo localmente.

Primero creamos un bucket:

aws --endpoint-url=http://localhost:4566 s3 mb s3://demo-local

Luego creamos un archivo de prueba:

echo "Probando S3 local con Floci" > prueba.txt

Ahora subimos ese archivo al bucket:

aws --endpoint-url=http://localhost:4566 s3 cp prueba.txt s3://demo-local/prueba.txt

Y para confirmar que el archivo está dentro del bucket:

aws --endpoint-url=http://localhost:4566 s3 ls s3://demo-local

Con eso ya probaste un flujo básico de S3 sin tocar AWS real.

Creaste un bucket.
Subiste un archivo.
Listaste el contenido.

Todo desde tu máquina.

Ejemplo práctico con S3

Imagina que estás desarrollando una aplicación donde un usuario puede subir archivos.

El flujo podría verse así:

Usuario sube archivo
La aplicación recibe el archivo
La aplicación lo guarda en S3
Otro proceso puede leerlo después

Antes de crear el bucket real en AWS, puedes probar la parte básica localmente.

Por ejemplo, puedes validar que tu aplicación sabe enviar el archivo, que el nombre del objeto se genera correctamente y que luego puedes consultarlo.

Eso te permite avanzar más rápido.

Si algo falla, estás local.

No dañaste nada.
No gastaste nada.
No dejaste recursos olvidados.

Y cuando ya el flujo funciona, ahí sí puedes pasar a una cuenta real de AWS y validar el comportamiento completo con permisos, seguridad, monitoreo y configuración real.

Probando SQS localmente

SQS es un servicio de colas de mensajes.

Dicho de forma simple: una parte de tu aplicación deja un mensaje en una cola y otra parte lo procesa después.

Esto se usa mucho cuando no quieres que todo pase al mismo tiempo.

Por ejemplo, imagina una tienda online.

Cuando un cliente hace una compra, la aplicación no necesariamente tiene que procesarlo todo en ese mismo segundo.

Puede guardar la orden, mandar un mensaje a una cola y dejar que otro proceso se encargue del resto.

El flujo sería algo así:

Cliente hace una compra
La API recibe la orden
La API manda un mensaje a SQS
Un worker procesa ese mensaje después

Eso ayuda a desacoplar sistemas y a manejar mejor los procesos en segundo plano.

Con Floci puedes probar ese mismo concepto localmente.

Primero creamos una cola:

aws --endpoint-url=http://localhost:4566 sqs create-queue \
  --queue-name ordenes-locales

Luego enviamos un mensaje:

aws --endpoint-url=http://localhost:4566 sqs send-message \
  --queue-url http://localhost:4566/000000000000/ordenes-locales \
  --message-body '{"ordenId":"123","estado":"pendiente"}'

Y después leemos el mensaje desde la cola:

aws --endpoint-url=http://localhost:4566 sqs receive-message \
  --queue-url http://localhost:4566/000000000000/ordenes-locales

Con eso ya probaste un flujo básico de mensajería.

Creaste una cola.
Enviaste un mensaje.
Leíste el mensaje.

Todo localmente.

Ejemplo práctico con SQS

Supongamos que tienes una aplicación que procesa órdenes.

Cuando llega una orden nueva, no quieres que la API haga todo el trabajo pesado de una vez.

Entonces la API puede mandar un mensaje como este:

{
  "ordenId": "123",
  "estado": "pendiente"
}

Luego otro proceso, que puede ser un worker, lee ese mensaje y se encarga de procesarlo.

Ese worker podría hacer cosas como:

Validar la orden
Enviar una notificación
Procesar un pago
Actualizar el estado
Generar un reporte

Lo bueno de probar esto localmente es que puedes validar la lógica antes de conectar todo a AWS real.

Puedes confirmar que el mensaje se manda bien, que el worker lo recibe y que tu aplicación entiende la estructura del mensaje.

Y si te equivocas, simplemente ajustas y vuelves a probar.

Sin presión.

Entonces, ¿cuándo usar Floci?

Floci tiene mucho sentido cuando estás aprendiendo, creando demos o desarrollando.

Puede ayudarte cuando quieres:

Practicar comandos de AWS CLI
Probar flujos de almacenamiento
Probar colas de mensajes
Crear demos técnicas
Validar código localmente
Evitar costos innecesarios mientras aprendes

Pero hay algo importante que tener claro.

Floci no reemplaza AWS.

Una cosa es probar localmente y otra cosa es correr en un ambiente real.

Por eso, el flujo correcto sería:

Primero pruebo localmente
Luego valido en AWS real
Después automatizo o despliego

Así llegas más preparado a la nube real.

En este video hablo sobre qué es Floci y cómo puede ayudarte.

Puedes verlo aquí

Floci