Crear una EC2 bàsica amb seguretat mínima

Llençar una EC2 bàsica a AWS és una operació que, en teoria, hauríem de tenir molt mecanitzada. Però fins i tot després d’anys fent-ho, continuen sortint errors que no haurien de passar. No perquè siguin complexos, sinó perquè s’escapen en els detalls, sobretot quan tens pressa o estàs muntant una cosa que “només ha d’estar una estona”.

Configurar bé el security group des de l’ inici

És habitual crear el grup de seguretat amb un únic port obert: el 22 per a SSH. I per defecte, molta gent deixa l’accés lliure des de qualsevol IP (0.0.0.0/0). Lo típic amb la idea de tancar després. Aquest “després” moltes vegades no arriba.

No és només un tema d’exposició a atacs (que ja seria raó suficient). També té implicacions pràctiques. Si et connectes des d’una xarxa corporativa amb IP dinàmica, o des d’una VPN, i deixes la regla mal configurada, després no hi ha forma d’accedir-hi. O pitjor: et funciona mentre estàs connectat, però després no recordes quina IP poses i ja no tens accés.

El que cal fer ara és crear regles amb accés limitat a rangs coneguts (oficina, VPN personal, etc.) i, quan sigui estrictament necessari, obrir temporalment a una IP pública específica. Fins i tot pots automatitzar-ho amb scripts que afegeixin i esborrin regles segons la teva IP actual (per exemple, fent servir AWS CLI i una mica de bash).

Una altra cosa que ajuda: nomenar els security groups de forma clara. Alguna cosa com ec2-test-ssh-jgomez és infinitament més útil que sg-083a9e. No cal muntar una nomenclatura estricta, però sí evitar que tot sembli igual a la consola.

La clau privada .pem i els permisos que sempre s’obliden

Aquest error no desapareix per molts anys que portis en això. Et baixes la clau .pem, intentes connectar-te, i et salta:

Els permisos 0644 per a la-meva-clau.pem són massa oberts.

El remei és trivial (chmod 400 la-meva-clau.pem), però el fet de que el continuem veient diu prou. Sol passar quan estàs en una màquina nova, o quan re-descàrregues la clau en un entorn de CI/CD i no has gestionat els permisos correctament.

El problema seriós ve quan perds la clau. O si mai arribes a descarregar-la, perquè estaves en pilot automàtic i vas fer “següent, següent”. En aquest cas, recuperar l’accés és bastant més incòmode: has de muntar el volum arrel en una altra instància, canviar el contingut del /.ssh/authorized_keys des de fora, tornar a muntar… Tot per no haver guardat bé un arxiu de text pla.

Si sols fer proves amb freqüència, potser val la pena tenir una clau genèrica registrada en diversos entorns o fer servir Session Manager per accedir sense necessitat de SSH, sempre que la instància tingui permisos adequats.

Fallades silencioses a l’ user-data

Molts muntem petites configuracions a l’user-data en crear la instància: instal·lar un paquet, configurar un servei, deixar tot llest per a que funcioni sol. I després entres, i no ha passat res. L’script no va fallar… però tampoc va fer res.

El 90% dels errors venen per una cosa tan simple com oblidar el #!/bin/bash. A partir d’aquí, tota la resta deixa d’executar-se com esperes. L’altra meitat (perquè aquí els percentatges mai sumen 100) es deu al fet que els comandaments sí que s’executen, però fallen en silenci, o ho fan abans d’arribar al pas important.

Solució pràctica: incloure un log directe al principi de l’ script per tenir traçabilitat sense dependre de l’ historial de bash.

#!/bin/bash
exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1
set -eux

Amb això, almenys tens sortida clara. I si vols anar sobre segur, pots fer servir cloud-init correctament amb blocs YAML, tot i que per a tasques bàsiques el shell pla continua sent el més directe.

També és recomanable provar els comandaments d’user-data a mà en una EC2 ja llançada. No sempre és evident que un yum install fallarà perquè falta una clau GPG, o que no fa res si el servei no s’instal·la correctament.

Triar la subnet correcta marca la diferència

Aquest és un error que de vegades passa desapercebut durant força estona. Llences la instància, tot sembla anar bé, però no respon. Has obert els ports? Sí. Està corrent el servei? Sí. Té IP pública? També.

La causa sovint és més simple del que sembla: està en una subnet privada. I sense NAT. Ni Internet Gateway.

M’ha passat més d’una vegada llançar EC2s en una VPC personalitzada, amb diverses subnets, i donar per fet que estava a la pública. En realitat, estava en una subnet que només tenia accés intern. Resultat: no hi havia trànsit sortint, ni actualització de paquets, ni accés remot. Només un bonic timeout al client SSH.

Des d’aleshores tinc una VPC “sandbox” amb subnets públiques explícites, tags clars, i una taula de rutes que no deixa lloc a dubtes. I si en tinc de dubtes, sempre reviso a la consola si la subnet té associada una gateway de sortida. No costa res i estalvia frustracions.

Elastic IP només si de veritat la necessites

Quan crees una instància i actives l’assignació automàtica d’IP pública, tot sembla estar bé. Et connectes, proves el que sigui, i funciona. Però un dia reinicies la instància, i de sobte ja no respon. Per què? Perquè aquesta IP pública era dinàmica. AWS la va canviar en reiniciar.

Si la teva EC2 està integrada en algun sistema que depèn de la seva IP (webhooks, DNS, llistes d’accés en altres serveis), necessites una Elastic IP. Assignar-la costa zero si està en ús, però sí que té cost si la tens sense associar a res.

El meu costum és: si no necessito una IP fixa, deixo que la instància prengui la dinàmica i llest. Si vaig referenciar-la des de fora (per exemple, per configurar un API Gateway o un firewall extern), utilitzo una Elastic IP i deixo ben documentat per a què es fa servir.

I no oblidis revisar periòdicament si tens EIPs sense associar. És el tipus de residu que passa desapercebut i que al final suma.

Rols i permisos: millor limitar que improvisar

Quan estàs muntant alguna cosa de forma ràpida, és fàcil caure en el parany d’assignar un rol amb permisos genèrics. “AmazonEC2FullAccess”, “AdministratorAccess” i a córrer. Total, és només una prova. Fins que aquesta prova es converteix en un entorn semi-permanent i ningú s’enrecorda que aquesta EC2 pot tocar mig entorn d’AWS.

El mínim recomanable és tenir un rol per tipus de tasca. Per exemple, un que només pugui llegir de S3, un altre que tingui accés a CloudWatch, etc. Fins i tot per a proves, val la pena. AWS IAM té polítiques predefinides que solen ser suficients. I si no, pots copiar una base i retallar el que no necessitis.

També és bona idea revisar amb freqüència quines instàncies tenen rol assignat. Més d’una vegada em vaig trobar amb EC2s antigues amb permisos innecessaris simplement perquè ningú els va treure el rol quan van deixar de fer-lo servir.

Etiquetes: la diferència entre ordre i caos

Quan llances una EC2 per a alguna cosa puntual, costa justificar l’esforç d’etiquetar-la. “Total, és per avui i l’ esborro després”. Però quan portes diverses setmanes creant màquines per a diferents proves, acabes amb una dotzena d’instàncies que s’anomenen “ip-172-31-xx-xx” i no saps quina pots apagar sense trencar res.

Podem fer servir tres etiquetes bàsiques a totes les instàncies de prova:

1. Name: una cosa descriptiva, encara que sigui test-apache-port8080
2. Owner: útil si comparteixes entorn amb més persones
3. DataCreació: en format ISO (2025-05-30), per poder filtrar per antiguitat

Hi ha scripts i polítiques que eliminen recursos antics en funció d’ aquestes etiquetes. Fins i tot sense automatització, et permeten fer neteja sense por.

Tancar el que no es fa servir

El millor consell que em va donar un col·lega fa anys va ser: “Si no saps si el faràs servir demà, apaga-ho avui”. Sona dràstic, però és pràctic.

Moltes EC2s segueixen enceses perquè “potser la necessito després”. I passen els dies, se t’oblida, i quan revises els costos t’adones que portes pagant per CPU i disc que no han rebut res en setmanes.

Si tens CloudWatch activat, pots crear alarmes que t’avisin si la instància porta X hores sense trànsit de xarxa o sense ús de CPU. Una altra opció: programar apagats automàtics al final del dia. I si creus que podries necessitar-la de nou, crea una AMI o un snapshot abans d’esborrar-la.