Floci : guide pratique de l'emulateur AWS local gratuit

Floci est un emulateur AWS local, gratuit et open source. L’idee est simple : lancer un conteneur, pointer le SDK AWS ou l’AWS CLI vers http://localhost:4566, puis developper contre des services compatibles AWS sans compte cloud, sans token d’authentification, sans telemetrie imposee et sans fonctionnalites bloquees derriere une edition payante.

Je l’aborde ici comme mon propre guide d’apprentissage. La vraie question n’est pas “est-ce que c’est cool ?”, mais plutot : si je construis une application avec S3, SQS, DynamoDB, Lambda, IAM, RDS, EventBridge ou Cognito, est-ce que Floci peut devenir ma cible locale par defaut pour le developpement et la CI ?

La reponse courte : oui, pour beaucoup de workflows. La reponse complete demande de comprendre quatre points :

• Floci expose un endpoint compatible AWS sur le port 4566.
• Certaines ressources sont emulees directement, d’autres utilisent de vrais conteneurs Docker.
• Le stockage peut etre en memoire, persistant, hybride ou journalise.
• L’isolation multi-compte depend de l’access key utilisee.

Sources principales : GitHub Floci, documentation Floci, installation, configuration AWS CLI/SDK, stockage, multi-compte et migration LocalStack.

Le modele mental

Floci est un plan de controle AWS local.

Votre application continue d’utiliser les clients AWS habituels. Votre CLI envoie toujours des requetes au format AWS. Terraform, CDK, boto3, AWS SDK JavaScript ou Java pensent parler a AWS. La difference est l’endpoint :

export AWS_ENDPOINT_URL=http://localhost:4566
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test

Ensuite :

aws s3 mb s3://mon-bucket
aws sqs create-queue --queue-name jobs
aws dynamodb list-tables

L’architecture se separe en trois familles :

• Services in-process : rapides, geres directement par Floci.
• Services avec etat : S3, DynamoDB et autres ressources qui conservent des donnees.
• Services Docker-backed : Lambda, RDS, ElastiCache, MSK, EC2, ECS, EKS, OpenSearch, ECR ou CodeBuild utilisent de vrais conteneurs quand la fidelite runtime compte.

Demarrage rapide

Compose minimal :

services:
  floci:
    image: floci/floci:latest
    ports:
      - "4566:4566"
    volumes:
      - ./data:/app/data

Demarrer :

docker compose up

Configurer la CLI :

export AWS_ENDPOINT_URL=http://localhost:4566
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test

Tester :

aws s3 mb s3://learning-bucket
aws sqs create-queue --queue-name learning-queue
aws ssm put-parameter --name /demo/message --value "hello from floci" --type String
aws ssm get-parameter --name /demo/message

Quand monter le socket Docker

Pour les services Docker-backed, Floci doit pouvoir lancer des conteneurs :

docker run -d --name floci \
  -p 4566:4566 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e FLOCI_DEFAULT_REGION=us-east-1 \
  -u root \
  floci/floci:latest

Cela concerne notamment Lambda, RDS, ElastiCache, MSK, EKS, EC2, ECS, OpenSearch, ECR et CodeBuild.

Le compromis est clair :

• plus de fidelite runtime ;
• mais plus de ressources ;
• et une implication securite, car le socket Docker donne beaucoup de pouvoir au conteneur.

Modes de stockage

Exemple :

services:
  floci:
    image: floci/floci:latest
    ports:
      - "4566:4566"
    environment:
      FLOCI_STORAGE_MODE: hybrid
    volumes:
      - ./floci-data:/app/data

Mon choix pratique :

• memory pour les tests automatises ;
• hybrid pour le developpement quotidien ;
• wal seulement si la durabilite locale prime sur la vitesse.

Isolation multi-compte

Si AWS_ACCESS_KEY_ID contient exactement 12 chiffres, Floci l’utilise comme identifiant de compte.

AWS_ACCESS_KEY_ID=111111111111 aws sqs create-queue --queue-name orders
AWS_ACCESS_KEY_ID=222222222222 aws sqs create-queue --queue-name orders

Meme nom de queue, deux namespaces separes.

Choisissez un compte.

Migration depuis LocalStack

La migration minimale est souvent un changement d’image :

# avant
image: localstack/localstack

# apres
image: floci/floci:latest

Si vos scripts d’initialisation ont besoin de aws, boto3 ou Python dans le conteneur :

image: floci/floci:latest-compat

Quelques traductions utiles :

Le repertoire de donnees change aussi : LocalStack utilise souvent /var/lib/localstack; Floci utilise /app/data.

SDK et Testcontainers

Python boto3 :

import boto3

ssm = boto3.client(
    "ssm",
    endpoint_url="http://localhost:4566",
    region_name="us-east-1",
    aws_access_key_id="test",
    aws_secret_access_key="test",
)

ssm.put_parameter(Name="/demo/message", Value="hello", Type="String", Overwrite=True)
print(ssm.get_parameter(Name="/demo/message")["Parameter"]["Value"])

Node.js :

import { SQSClient, SendMessageCommand } from "@aws-sdk/client-sqs";

const sqs = new SQSClient({
  endpoint: "http://localhost:4566",
  region: "us-east-1",
  credentials: { accessKeyId: "test", secretAccessKey: "test" },
});

await sqs.send(new SendMessageCommand({
  QueueUrl: "http://localhost:4566/000000000000/demo-queue",
  MessageBody: "hello",
}));

Pour la CI, Testcontainers est le chemin propre : chaque suite lance son Floci isole, avec endpoint, region et credentials fournis par le conteneur.

Ce que je testerais avec Floci

Tres bon candidat :

• integration SDK AWS ;
• S3, SQS, SNS, SSM, Secrets Manager ;
• DynamoDB et indexes ;
• Lambda event-source mappings ;
• EventBridge ;
• workflows Cognito ;
• RDS/Postgres local ;
• tests multi-compte ;
• smoke tests Terraform/CDK/OpenTofu.

A garder pour un vrai compte AWS :

• validation finale IAM ;
• quotas et throttling reels ;
• comportements regionaux ;
• limites managees ;
• confiance pre-production.

Le bon pattern est :

1. tests rapides en local avec Floci ;
2. tests CI avec Floci/Testcontainers ;
3. petit set de tests contrat dans un compte AWS sandbox.

Limites a garder en tete

Floci emule beaucoup de services, mais il reste un emulateur. Certaines integrations sont completes, d’autres partielles ou stubbees. Les services comme Bedrock Runtime, Textract, ELBv2 ou OpenSearch peuvent avoir des limitations selon le mode utilise. Le projet bouge vite : les docs et le README peuvent temporairement diverger sur le nombre exact de services.

Le socket Docker est puissant et doit etre traite comme sensible. Les certificats TLS locaux peuvent demander une configuration speciale. Le mode memory perd l’etat a l’arret. Et une migration LocalStack n’est jamais garantie a 100% sans tester vos scripts d’init, chemins de donnees et variables d’environnement.

Mon takeaway

Floci est interessant parce qu’il ne se limite pas a un mock simple. Il propose un endpoint AWS-compatible local, des services Docker-backed quand la fidelite compte, plusieurs modes de stockage, une isolation multi-compte et une migration LocalStack assez directe.

Mon chemin d’apprentissage :

1. S3, SQS, SSM, DynamoDB.
2. Mode de stockage choisi explicitement.
3. Testcontainers.
4. Lambda ou RDS Docker-backed.
5. Tests multi-compte.

Quand ces cinq points fonctionnent, Floci devient une surface fiable pour apprendre, developper et tester des systemes cloud avant de payer le cout d’un vrai environnement AWS.