Category: Cloud free-tier

Per chi gestisce un homelab e ogni tanto vuole appoggiare qualcosa “in cloud” (un backup off-site, una landing page, un endpoint sempre raggiungibile), i tier gratuiti dei big cloud sono un’opportunità enorme che spesso resta non sfruttata. La curva di apprendimento iniziale è fastidiosa, ma una volta capita la mappa si possono mettere in produzione cose serie con costo annuale zero.

Riassumo come uso oggi i principali tier gratuiti, senza esporre numeri di account o tenant miei.

Oracle Cloud Infrastructure Always Free

Il più generoso dei tier “always free” attualmente in giro: 4 OCPU ARM Ampere A1 + 24 GB RAM da spalmare su una o più VM, 200 GB di block storage, 10 GB di object storage standard + 10 GB archive, un Autonomous Database da 20 GB. “Always free” vuol dire che non scade dopo 12 mesi (a differenza del free tier AWS che è tempo-limitato).

Per creare una VM A1 ARM via CLI, una volta configurato oci-cli:

oci compute instance launch \
  --availability-domain AD-1 \
  --compartment-id COMPARTMENT_OCID \
  --shape VM.Standard.A1.Flex \
  --shape-config '{"ocpus": 2, "memoryInGBs": 12}' \
  --image-id IMAGE_OCID \
  --subnet-id SUBNET_OCID \
  --display-name homelab-aux

COMPARTMENT_OCID è nel formato ocid1.compartment.oc1.. seguito da identificativo. Lo recupero con oci iam compartment list, così come IMAGE_OCID e SUBNET_OCID. Mai metterli in chiaro su repository pubblici.

Cosa ci faccio sopra: una VM ARM piccola che fa da bastion SSH off-site verso il mio homelab via Tailscale, e ospita servizi che voglio sempre raggiungibili anche quando casa va giù (DNS secondario, status page). Un’altra VM A1 ospita una replica InfluxDB di sola lettura come backup metriche.

AWS Free Tier

Il free tier AWS Always Free include 1 milione di invocazioni Lambda e 400.000 GB-secondi al mese, 25 GB DynamoDB, 1 milione di richieste DynamoDB e 100 GB di egress CloudFront. Il free a 12 mesi aggiunge 750 ore EC2 t2.micro (che scadono), 5 GB S3, 750 ore RDS.

Per un homelab si vive bene con il solo “always free”: Lambda + DynamoDB + S3 (qui si paga storage > 5 GB anche always, ma centesimi). Esempio di upload backup su bucket con storage class IA:

aws s3 mb s3://mio-backup-offsite-ACCOUNT_ID --region eu-west-1
aws s3 cp /var/backups/db.sql.gz s3://mio-backup-offsite-ACCOUNT_ID/ \
  --storage-class STANDARD_IA

STANDARD_IA costa metà di STANDARD per oggetti che non leggo spesso, con il vincolo di mantenere il file almeno 30 giorni in classe IA.

Google Cloud Platform Free Tier

GCP offre un free tier “always free” più modesto ma utile: una e2-micro in us-west1/us-central1/us-east1, 30 GB HDD, 5 GB Cloud Storage standard, 1 GB egress fuori dal Nord America. L’e2-micro non basta per molto, ma per un ping checker o un piccolo cron job sì.

Cloudflare Workers e R2

Cloudflare ha un free tier dei più pratici per un homelab. 100.000 richieste Workers al giorno, 10 GB R2 storage, 1 milione classe A operations e 10 milioni classe B operations al mese. Niente egress per R2 (è il vero killer feature rispetto a S3).

Esempio di Worker minimale che risponde a un health check:

npm create cloudflare@latest -- mio-health-worker
cd mio-health-worker
wrangler deploy

Lo uso per pingare i miei servizi homelab via Tailscale subnet router e scriverne lo stato su KV. Il worker risponde in 30-80 ms da edge, e ho un endpoint pubblico per status page senza esporre infrastruttura mia.

Un caso reale

Un paio di mesi fa pagavo 7 euro al mese per una piccola VPS che ospitava un endpoint HTTPS per ricevere webhook di terze parti. Ho passato un pomeriggio a riscriverlo come Worker Cloudflare con storage su KV e ho dismesso la VPS. Conto annuale: -84 euro. Latenza del nuovo endpoint dimezzata (rispetto al VPS in singola region) e affidabilità superiore (Cloudflare edge globale). Il deploy del worker, comprese le variabili di ambiente, sta in venti righe di wrangler.toml e un singolo file index.ts. Il TCO totale di quel servizio è passato da 84 euro a 0,00 euro l’anno.

Cosa funziona bene

Ogni cloud ha tier complementari: OCI ti dà compute ARM serio (per VM Linux che girano 24/7), AWS ti dà serverless (Lambda+DynamoDB), GCP ti dà micro-istanze e BigQuery free, Cloudflare ti dà edge globale e storage senza egress. Mischiandoli, copri quasi ogni esigenza tipica di un homelab senza pagare.

Limiti

I tier gratuiti cambiano. AWS ha già rimodulato il suo free tier in passato, OCI ha avuto problemi di disponibilità ARM in certe region. Il vendor lock-in è reale anche su free: una Lambda non si sposta facilmente su Workers. Inoltre, oltre certi consumi le fatture esistono e possono fare male: configuro sempre alerting di billing a 1 euro/giorno per ogni account, e budget hard a zero dove possibile.

In pratica

Free tier cloud è una leva tecnica preziosa per chi gestisce un homelab. Permette di avere componenti in cloud sempre acceso (DNS secondario, status page, backup off-site, webhook endpoint) senza spese ricorrenti. La gestione costa un po’ di tempo iniziale, ma una volta scritto il setup come Infrastructure-as-Code (Terraform o equivalente), replicare è banale. E quando un servizio cresce oltre il free tier, si decide a ragion veduta se mantenerlo in cloud o portarlo sull’hardware di casa.

---

Immagine generata con Cloudflare Workers AI / FLUX.

Il mio homelab è cresciuto a strati: qualche Raspberry Pi sulla scrivania, un paio di mini PC e una manciata di VM su provider con tier gratuiti. A un certo punto mi sono ritrovato a valutare un servizio di monitoring SaaS che mi avrebbe portato via 5 euro al mese per controllare una decina di host. Non aveva senso, perché lo stesso lavoro lo posso fare con una Lambda e una tabella DynamoDB restando dentro il piano Always Free di AWS. Costo a regime: zero.

Qui racconto come l’ho costruito senza tirare in ballo identificativi del mio account.

L’architettura in due righe

Ogni host pubblica un evento JSON (uptime, carico, spazio disco, stato di un servizio) verso un endpoint HTTPS. L’endpoint è una funzione Lambda dietro un Function URL che valida un HMAC SHA-256 con segreto condiviso e scrive una riga su DynamoDB. Una seconda Lambda parte ogni cinque minuti tramite una regola EventBridge, legge le righe recenti e, se trova qualcosa fuori soglia, manda una notifica via webhook.

Il piano Always Free di Lambda offre 1 milione di invocazioni e 400.000 GB-secondi al mese. DynamoDB on-demand resta dentro la franchigia fino a 25 GB di storage e 200 milioni di richieste al mese. Per dieci host che pingano una volta al minuto si parla di circa 432.000 invocazioni mensili, ben dentro al tier.

Setup Lambda

Funzione Python 3.12, handler che valida HMAC e scrive su tabella. Il comando per crearla dal terminale fish del portatile:

aws lambda create-function \
  --function-name homelab-ingest \
  --runtime python3.12 \
  --handler app.handler \
  --role arn:aws:iam::ACCOUNT_ID:role/homelab-ingest-role \
  --zip-file fileb://function.zip

ACCOUNT_ID resta come placeholder. Il ruolo IAM ha solo dynamodb:PutItem sulla tabella di destinazione, niente wildcard e niente policy gestite generaliste.

Il Function URL lo configuro con auth NONE ma con HMAC obbligatorio nel body, validato dentro la funzione:

aws lambda create-function-url-config \
  --function-name homelab-ingest \
  --auth-type NONE

Setup DynamoDB

Tabella semplice, partition key host, sort key ts (timestamp epoch), modalità on-demand per non doversi preoccupare del capacity planning:

aws dynamodb create-table \
  --table-name homelab-metrics \
  --attribute-definitions AttributeName=host,AttributeType=S AttributeName=ts,AttributeType=N \
  --key-schema AttributeName=host,KeyType=HASH AttributeName=ts,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST

Per limitare i costi nel caso qualcosa vada storto, attivo un TTL a sette giorni con un attributo expire_at e abilito il TTL sulla tabella:

aws dynamodb update-time-to-live \
  --table-name homelab-metrics \
  --time-to-live-specification "Enabled=true, AttributeName=expire_at"

Allarmi e notifica

La Lambda di check parte da una regola EventBridge ogni cinque minuti, legge le righe degli ultimi dieci minuti per ogni host e confronta le soglie. Se un host non scrive da più di due intervalli, lo considero down. Per il fan-out delle notifiche uso un webhook generico verso un endpoint personale che converte il payload in un messaggio Telegram o un’email Resend. Lambda e DynamoDB restano l’unica spesa infrastrutturale, e quella spesa è esattamente zero.

Un caso reale

Una sera tardi, intorno alle 23:40, ho ricevuto la prima notifica seria dal nuovo stack. Un host di edge che da diversi mesi girava senza inghippi aveva smesso di inviare metriche. La Lambda di check, dopo dieci minuti di silenzio, ha emesso il webhook e mi è arrivato un alert sul telefono. Ho aperto la sessione SSH e ho trovato il filesystem in read-only per un errore I/O sull’SSD USB. Senza il monitor avrei scoperto il problema solo il giorno dopo, con i servizi giù da diverse ore. Il costo dell’infrastruttura di alerting quel mese è stato 0,00 dollari sul billing AWS, voce per voce.

Cosa funziona bene

Il modello pull-by-cron + push-da-host è semplicissimo da debuggare: i log della Lambda di ingest stanno in CloudWatch con retention a una settimana, e il payload è leggibile a occhio. La sicurezza la concentro sul segreto HMAC e sul ruolo IAM minimale, non devo gestire endpoint esposti senza autenticazione.

Limiti

Latenza fra evento e notifica sta sui 5-10 minuti, perché il check parte a intervalli fissi. Per scenari mission-critical non basta. Inoltre il free tier AWS può cambiare le clausole, quindi una volta l’anno controllo che il consumo effettivo resti dentro le voci Always Free, non quelle a 12 mesi.

In pratica

Questo stack lo uso come secondo livello, in parallelo a un check su uptime self-hosted in LAN. Se domani decidessi di spegnere tutto e tenere solo un servizio per sapere se il fuoco di casa è ancora vivo, è questo: leggero, isolato, indipendente dalla mia infrastruttura locale, e a costo zero finché AWS tiene fede al piano Always Free.

---

Immagine generata con Cloudflare Workers AI / FLUX.