Tancàvem el mòdul 2 amb una constatació incòmoda: MercadoFresco ja té a eu-west-1 un grup d'Auto Scaling, discs amb còpies automàtiques, el catàleg a S3, la base de dades a RDS i dues funcions Lambda… i tot això viu a la VPC per defecte. És a dir, en una xarxa que AWS va crear sola el dia que es va obrir el compte, amb totes les subxarxes públiques, amb la base de dades compartint espai de xarxa amb la botiga i amb la instància mercadofresco-tienda-01 accessible des d'internet sense que ningú no ho hagi decidit conscientment.

Una VPC (Virtual Private Cloud) és el teu propi centre de dades virtual dins d'AWS: un espai de xarxa aïllat, amb el rang d'adreces IP que tu triïs, dividit en subxarxes que tu col·loques a les zones de disponibilitat que vulguis, amb les rutes que tu defineixis. És la capa sobre la qual s'apuntala absolutament tota la resta. Un balancejador es col·loca en subxarxes. Una base de dades viu en un grup de subxarxes. Un grup de seguretat pertany a una VPC. Si la xarxa està mal dissenyada, tot el que es construeixi a sobre arrossega el problema.

En aquesta lliçó la Marta dissenya i construeix des de zero la xarxa definitiva de MercadoFresco: vpc-mercadofresco, amb sis subxarxes repartides en dues zones de disponibilitat, tres nivells d'aïllament, sortida controlada a internet i una base de dades que deixa de ser abastable des de fora.

1. Què és una VPC i per què la VPC per defecte no serveix per a producció
2. Adreçament: CIDR, màscares i com triar el rang
3. Les cinc IP que AWS reserva a cada subxarxa
4. Per què no s'ha de solapar amb la xarxa de l'oficina
5. El disseny de xarxa de MercadoFresco: sis subxarxes en dues AZ
6. Internet Gateway i què fa realment que una subxarxa sigui «pública»
7. Taules de rutes: principal, personalitzades, associacions i la ruta local
8. NAT Gateway i NAT instance: per a què serveixen i quant costen de debò
9. Adreces IP privades, públiques, elàstiques i interfícies de xarxa
10. Punts d'enllaç de VPC: de passarel·la i d'interfície
11. DNS dins de la VPC
12. Connectar amb l'oficina: peering, Transit Gateway, VPN i Direct Connect
13. Construcció completa de vpc-mercadofresco per CLI
14. Moure la base de dades mercadofresco-pedidos a les subxarxes privades de dades
15. VPC Flow Logs: el registre del que passa per la xarxa
16. Neteja i control de cost

Una VPC és una xarxa virtual aïllada lògicament de la resta de clients d'AWS. Viu en una regió (la nostra, eu-west-1) i s'estén automàticament per totes les seves zones de disponibilitat. A dins hi crees subxarxes, i cada subxarxa viu en una sola zona de disponibilitat. Aquesta és la regla que governa tot el disseny: la VPC és regional, la subxarxa és zonal.

Quan AWS crea un compte nou, genera a cada regió una VPC per defecte amb un disseny pensat perquè qualsevol cosa funcioni al primer intent. Aquest és exactament el seu problema.

El punt crític és el penúltim. A la VPC per defecte, l'única cosa que impedeix que qualsevol des d'internet obri una connexió a la base de dades de comandes és el grup de seguretat. Un grup de seguretat és una regla, i les regles s'editen per error un divendres a les set de la tarda. En una subxarxa privada no hi ha cap ruta cap a internet: encara que algú obrís el port 5432 a 0.0.0.0/0, no hi hauria camí de tornada. Això no és una regla, és física de la xarxa. Això se'n diu defensa en profunditat, i és la raó per la qual aquest disseny mereix la feina.

CIDR (Classless Inter-Domain Routing) és la notació adreça/màscara amb què es descriu un rang d'adreces IP. A 10.0.0.0/16, el /16 significa que els primers 16 bits són fixos (el 10.0.) i els 16 restants són variables: això dóna 2^16 = 65.536 adreces, des de 10.0.0.0 fins a 10.0.255.255.

La regla mental: com més gran és el número després de la barra, més petita és la xarxa. Cada bit que hi afegeixes divideix el rang per dos.

Els rangs privats que pots fer servir (definits al RFC 1918) són:

• 10.0.0.0/8 — de 10.0.0.0 a 10.255.255.255. Gairebé 17 milions d'adreces.
• 172.16.0.0/12 — de 172.16.0.0 a 172.31.255.255. Aquí hi viu la VPC per defecte.
• 192.168.0.0/16 — de 192.168.0.0 a 192.168.255.255. El clàssic dels routers domèstics.

La Marta tria 10.0.0.0/16 per tres raons concretes:

1. És el màxim que AWS permet per a una VPC (/16). El CIDR principal d'una VPC no es pot reduir ni canviar un cop creada; només s'hi poden afegir blocs secundaris. Començar petit «perquè no necessitem tantes IP» és l'error que més migracions ha costat.
2. No és 172.31.x.x, així que mai no xocarà amb la VPC per defecte si algun dia s'ha de fer peering entre totes dues.
3. No és 192.168.x.x, que és exactament el que fa servir el router de l'oficina de MercadoFresco.

Sobre el punt 1, una xifra per calibrar: MercadoFresco té avui 2 instàncies de botiga i arriba a 4 al pic dels divendres. Amb 4.091 adreces per subxarxa d'aplicació, el marge és de tres ordres de magnitud. Les adreces IP privades no costen diners. Ser generós aquí és gratis; ser garrepa es paga amb una migració de xarxa d'aquí a dos anys.

En qualsevol subxarxa, AWS es queda cinc adreces que no pots assignar a res. Prenent com a exemple 10.0.0.0/20 (de 10.0.0.0 a 10.0.15.255):

Per això un /28 amb 16 adreces només en dóna 11 d'utilitzables, i per això /28 és el mínim: per sota no en quedaria pràcticament cap. L'adreça .2 mereix ser recordada: quan a la lliçó 03-05 configurem regles de reenviament de DNS, aquesta és l'adreça amb què parlaran totes les instàncies.

L'oficina de MercadoFresco fa servir 192.168.10.0/24 per als seus equips i el seu NAS. La Marta ho documenta abans de crear res, perquè en el moment en què es vulgui connectar l'oficina amb AWS —per VPN, com veurem al final de la lliçó— els rangs solapats fan la connexió impossible.

El motiu és pur encaminament. Si el portàtil del Luis és 192.168.10.25 i a AWS existís també una instància 192.168.10.25, quan el portàtil volgués parlar amb la instància miraria la seva pròpia taula de rutes, veuria que 192.168.10.0/24 és «la meva xarxa local» i enviaria el paquet al switch del costat. Mai no creuaria el túnel. I no hi ha cap ajust que ho arregli: caldria renumerar una de les dues xarxes senceres.

La regla que segueix la Marta i que convé adoptar: un document únic amb el mapa de tots els rangs de l'empresa, inclosos els que encara no existeixen.

El patró que construirem és l'estàndard de la indústria: tres capes × dues zones de disponibilitat. Cada capa té un nivell d'exposició diferent i una taula de rutes diferent.

Queden lliures els rangs de 10.0.96.0 en endavant: més de la meitat de la VPC sense fer servir, disponible per a futures capes (contenidors al mòdul 10, memòria cau al 06-05) sense tocar res del que ja existeix.

Tres decisions de disseny que convé entendre:

• La capa d'aplicació és privada. Les instàncies de la botiga no tindran IP pública. Rebran el trànsit a través del balancejador (lliçó 03-03) i sortiran a internet, quan ho necessitin, pel NAT Gateway.
• La capa de dades no té cap ruta a internet, ni tan sols per NAT. RDS no necessita descarregar res. Com menys camí hi hagi, menys superfície d'atac.
• Tot està duplicat en dues AZ. Si eu-west-1a cau sencera, eu-west-1b té subxarxa pública (per al balancejador), subxarxa d'aplicació (per a les instàncies) i subxarxa de dades (per a la còpia en espera de RDS). Aquesta és la raó pràctica del disseny multi-AZ que vam estudiar a 01-03.

Un Internet Gateway (IGW) és un component gestionat, redundant i escalat horitzontalment per AWS que s'adjunta a una VPC (un de sol per VPC) i fa dues coses:

1. Proporciona la destinació per al trànsit dirigit a internet.
2. Tradueix (NAT 1:1) la IP privada d'una instància a la seva IP pública, en tots dos sentits.

I aquí hi ha el concepte que més confusió genera de tota la lliçó:

No existeix cap casella anomenada «subxarxa pública». Una subxarxa és pública si —i només si— la taula de rutes associada a ella conté una entrada 0.0.0.0/0 que apunta a un Internet Gateway. Això és tot. El nom que li posis és decoratiu.

D'aquí se'n deriven dues conseqüències molt pràctiques:

• Una instància amb IP pública en una subxarxa sense ruta a l'IGW no té internet. Té una IP que no serveix de res.
• Una instància sense IP pública en una subxarxa amb ruta a l'IGW tampoc no té internet: l'IGW necessita una IP pública per traduir.

És a dir, perquè una instància parli amb internet directament calen les dues coses alhora: ruta a l'IGW i IP pública (o elàstica).

Una taula de rutes és una llista de regles «per arribar a aquesta destinació, envia per aquí». Cada subxarxa està associada a exactament una taula de rutes; una taula pot servir moltes subxarxes.

Tota VPC neix amb una taula principal (main), que s'aplica a qualsevol subxarxa que no tinguis associada explícitament a una altra. I tota taula conté una ruta local que no es pot esborrar ni modificar:

Aquesta ruta local és la que fa que la instància de la botiga pugui parlar amb RDS sense que hi hagi cap configuració addicional: dins d'una VPC, totes les subxarxes s'abasten entre elles per defecte, siguin a l'AZ que siguin. El que decideix si aquesta conversa es permet no és la ruta, són els grups de seguretat, que és exactament el tema de la lliçó 03-02.

Les tres taules de MercadoFresco queden així:

Fixa't que hi ha dues taules separades per a la capa d'aplicació, una per AZ. És deliberat: si app-a i app-b compartissin taula, totes dues sortirien pel mateix NAT Gateway, i si aquest NAT caigués amb la seva AZ, les instàncies de l'altra zona es quedarien sense sortida. Amb una taula per AZ, cada zona és autosuficient.

AWS aplica sempre la ruta més específica que coincideixi (longest prefix match). Si una taula té 0.0.0.0/0 → NAT i 52.94.0.0/16 → IGW, un paquet a 52.94.10.1 va per l'IGW perquè /16 és més específic que /0.

Les instàncies de la capa d'aplicació no tenen IP pública, però necessiten sortir a internet: descarregar pedaços de seguretat, instal·lar paquets amb dnf, cridar la passarel·la de pagament. Necessiten connexions sortints sense acceptar-ne d'entrants. Per a això hi ha el NAT Gateway.

El NAT Gateway es col·loca en una subxarxa pública, té una IP elàstica, i fa d'intermediari: rep el paquet de la instància privada, el reenvia a internet amb la seva pròpia IP pública i retorna la resposta. Com que la conversa sempre la inicia la instància, ningú no pot iniciar una connexió des d'internet cap a dins.

⚠️ Avís de cost: el NAT Gateway és el recurs que més factures sorpresa genera

A eu-west-1 un NAT Gateway costa aproximadament 0,048 USD per hora més 0,048 USD per GB processat. Amb dos NAT Gateway (un per AZ) funcionant tot el mes:

• 2 × 0,048 × 730 h = ≈ 70 USD/mes només per existir, sense transferir ni un sol byte.
• Més 0,048 USD per cada GB que hi passi, en tots dos sentits.

No és a la capa gratuïta. Si segueixes el curs en un compte de proves amb el pressupost de 10 USD que vam configurar a 01-02, l'alerta a [email protected] saltarà en menys d'una setmana. Opcions:

• Un sol NAT Gateway per a proves (≈ 35 USD/mes): crea només nat-mercadofresco-a i fes que les dues taules d'aplicació hi apuntin. Perds la tolerància a fallades de zona, que en un entorn de proves no importa.
• Cap NAT: si només vols practicar l'adreçament, salta't el NAT i fes servir Session Manager (vist a 02-01) per arribar a les instàncies. Sense NAT no podran actualitzar paquets, però la xarxa s'estudia igual.
• Esborra'l en acabar cada sessió de pràctica. Hi ha comandes de neteja al final de la lliçó.

L'alternativa històrica és la NAT instance: una EC2 normal amb reenviament d'IP activat i la comprovació d'origen/destinació desactivada. Comparació honesta:

Per a MercadoFresco en producció: NAT Gateway, dos, un per AZ. Per a qui segueixi el curs al seu compte personal: una NAT instance t4g.nano o directament cap.

I una tercera via, la més elegant, que veurem a l'apartat de punts d'enllaç: treure del NAT tot el trànsit que en realitat va a serveis d'AWS.

Quatre conceptes que es confonen constantment:

L'ENI (Elastic Network Interface) és la peça que ho unifica tot. Una ENI pertany a una subxarxa, té una o diverses IP privades, opcionalment una IP pública o elàstica, una adreça MAC i els grups de seguretat. Quan dius «aquesta instància és a la subxarxa X amb el grup de seguretat Y», el que en realitat estàs descrivint és la seva ENI.

Això explica coses que d'altra manera semblen màgiques:

• RDS, un ALB o una Lambda a la VPC no són màquines que vegis, però consumeixen IP de les teves subxarxes: cadascun crea les seves ENI. Un ALB pot crear vuit ENI o més en escalar. Una altra raó per no fer subxarxes petites.
• Una EIP associada a una ENI es pot moure a una altra instància en segons, cosa que permet substituir una màquina sense canviar el DNS.

Parany clàssic de facturació: una IP elàstica assignada i en ús és gratis; una IP elàstica reservada i sense associar a res costa ≈ 0,005 USD/hora (≈ 3,6 USD/mes). Les EIP òrfenes que queden després d'esborrar una instància són la despesa fantasma més habitual en comptes d'aprenentatge.

Quan la instància mercadofresco-tienda-01, ja en una subxarxa privada, demana una foto de mercadofresco-catalogo-fotos, per on va aquest trànsit? Per defecte: instància → NAT Gateway → Internet Gateway → xarxa pública d'AWS → S3. Surt a internet per tornar a entrar a AWS. I per cada GB es paga el NAT.

Els punts d'enllaç de VPC eliminen aquesta volta: porten el trànsit als serveis d'AWS per la xarxa interna d'AWS, sense passar per internet. N'hi ha de dos tipus i funcionen de manera completament diferent.

Per a MercadoFresco, el punt d'enllaç de passarel·la cap a S3 és una decisió sense discussió: és gratis i estalvia diners des del primer byte.

El que és interessant del mecanisme: en crear el punt d'enllaç, AWS afegeix a les teves taules de rutes una entrada la destinació de la qual és una prefix list gestionada (pl-6da54004 per a S3 a eu-west-1), que conté tots els rangs IP públics d'S3 a la regió. Com que aquesta ruta és més específica que 0.0.0.0/0, el trànsit a S3 es desvia al punt d'enllaç i la resta continua anant pel NAT. No cal canviar ni una línia de codi de l'aplicació.

A més, un punt d'enllaç de passarel·la admet una política de punt d'enllaç que restringeix què s'hi pot fer:

Aquesta política diu: per aquest punt d'enllaç només es pot llegir i escriure als dos buckets de MercadoFresco. Si una instància compromesa intentés pujar dades a un bucket d'un atacant, el punt d'enllaç ho rebutjaria. Principal: "*" aquí no vol dir «qualsevol des d'internet»: només pot entrar per aquest punt d'enllaç qui estigui dins de la VPC.

Els punts d'enllaç d'interfície que MercadoFresco acabarà necessitant (ssm, ssmmessages, ec2messages per a Session Manager, i secretsmanager per al que veurem a 04-03) sí que costen diners, però permeten una cosa valuosa: fer servir Session Manager en instàncies sense NAT i sense internet en absolut.

Tota VPC porta incorporat un resolutor DNS, el Route 53 Resolver, accessible a l'adreça .2 de la VPC (10.0.0.2 en el nostre cas) i també a l'adreça local 169.254.169.253. És el que tradueix mercadofresco-pedidos.abc123.eu-west-1.rds.amazonaws.com a la IP privada correcta.

Dos atributs de la VPC governen el seu comportament i confonen tothom:

Una VPC creada amb create-vpc té enableDnsSupport=true però enableDnsHostnames=false. És el primer ajust que cal corregir després de crear-la, i la causa número u que un punt d'enllaç d'interfície «no funcioni».

MercadoFresco encara té l'ERP en un servidor de l'oficina. Tard o d'hora caldrà connectar les dues xarxes. Les quatre opcions, que no desenvolupem aquí perquè excedeixen l'abast del curs, però que convé saber anomenar:

Per a MercadoFresco, la tria natural quan arribi el moment és Site-to-Site VPN cap a vpc-mercadofresco: es munta en una tarda i funciona precisament perquè 10.0.0.0/16 i 192.168.10.0/24 no se solapen, tal com vam decidir al principi de la lliçó.

Ho construirem tot amb AWS CLI v2 i el perfil mercadofresco-dev que vam configurar a 01-05. Cada bloc desa l'identificador que retorna per fer-lo servir al següent.

--query 'Vpc.VpcId' --output text extreu només l'identificador, sense cometes ni JSON, per poder desar-lo en una variable de shell. És el patró de JMESPath que vam veure a 01-05 i que farem servir a tot el mòdul.

--map-public-ip-on-launch és una comoditat, no una decisió de seguretat: recorda que sense la ruta a l'IGW aquella IP pública no serviria de res.

Nota important: el NAT Gateway es crea a la subxarxa pública ($PUB_A), no a la privada. És l'error de col·locació més freqüent: si el poses a la subxarxa privada, el NAT no té sortida i res no funciona, sense cap missatge que ho expliqui.

Repeteix el bloc amb $PUB_B per a nat-mercadofresco-b, o salta-te'l si estàs en mode econòmic i fes que les dues taules d'aplicació apuntin a $NAT_A.

En indicar --route-table-ids, AWS insereix automàticament la ruta cap a la prefix list d'S3 en aquestes tres taules. Comprova-ho:

La instància RDS creada a 02-04 encara viu al grup de subxarxes sng-mercadofresco, que apuntava a la VPC per defecte. Cal crear un grup nou dins de vpc-mercadofresco:

Advertència operativa: una instància RDS no es pot moure de VPC canviant el seu grup de subxarxes. El camí real és: fer una instantània, restaurar-la indicant el nou grup de subxarxes, i reapuntar l'aplicació. A MercadoFresco, la Marta ho fa de matinada un dimarts:

aws rds create-db-snapshot --profile mercadofresco-dev --region eu-west-1 \\
  --db-instance-identifier mercadofresco-pedidos \\
  --db-snapshot-identifier mercadofresco-pedidos-premigracion

aws rds wait db-snapshot-completed --profile mercadofresco-dev --region eu-west-1 \\
  --db-snapshot-identifier mercadofresco-pedidos-premigracion

aws rds restore-db-instance-from-db-snapshot --profile mercadofresco-dev --region eu-west-1 \\
  --db-instance-identifier mercadofresco-pedidos-v2 \\
  --db-snapshot-identifier mercadofresco-pedidos-premigracion \\
  --db-subnet-group-name sng-mercadofresco-datos \\
  --multi-az --no-publicly-accessible

El --no-publicly-accessible és tan important com el grup de subxarxes: encara que la subxarxa no tingui ruta a internet, l'atribut PubliclyAccessible en true faria que RDS intentés resoldre a una IP pública i trencaria la connexió des de dins.

Els VPC Flow Logs capturen metadades de cada flux de trànsit IP: origen, destinació, ports, protocol, bytes, paquets i —el més valuós— si el flux va ser ACCEPT o REJECT. No en capturen el contingut, només les capçaleres.

Es poden activar a tres nivells: VPC sencera, subxarxa o interfície de xarxa. I es poden enviar a CloudWatch Logs (consulta interactiva, més car) o a S3 (barat, per a anàlisi massiva).

Un registre té aquest aspecte:

Llegit per parts: versió, compte, ENI, IP origen, IP destinació, port origen, port destinació, protocol (6 = TCP), paquets, bytes, inici, fi, acció i estat. Aquest ACCEPT/REJECT final és l'eina de diagnòstic que farem servir a la lliçó 03-02 per saber si un problema de connectivitat el causa un grup de seguretat o una NACL. L'anàlisi amb CloudWatch Logs Insights i les alarmes associades s'estudien a 05-01; aquí n'hi ha prou de tenir-los encesos.

Cost a tenir en compte: els Flow Logs no tenen cost de servei propi, però sí que es paga l'emmagatzematge i la ingesta a S3 o a CloudWatch Logs. En una VPC amb trànsit intens, ALL pot generar diversos GB al dia; començar amb --traffic-type REJECT és una manera barata de tenir el que importa.

Si estàs practicant en un compte propi, això és el que cal esborrar i en aquest ordre, perquè AWS bloqueja l'esborrament d'un recurs del qual en depenguin d'altres:

Verificació final que no queda res cobrant:

Triar un CIDR massa petit. Un /24 per a tota la VPC sembla suficient fins que arriba el tercer servei. El CIDR principal no es pot canviar. Fes servir sempre /16: les IP privades són gratis.

Solapar rangs entre entorns. Producció 10.0.0.0/16 i desenvolupament també 10.0.0.0/16 és còmode fins al dia del peering. Reserva el mapa de rangs abans de crear la primera VPC.

Posar el NAT Gateway en una subxarxa privada. No donarà cap error en crear-lo, i res no funcionarà. El NAT va sempre en subxarxa pública; el que és privat és allò que el fa servir.

Un sol NAT Gateway per a dues AZ en producció. Estalvies 35 USD al mes i crees una dependència entre zones: si cau l'AZ del NAT, les instàncies de l'altra zona perden la sortida. En proves és raonable; en producció, no.

Oblidar enableDnsHostnames. Els punts d'enllaç d'interfície i algunes integracions de RDS fallen de maneres incomprensibles. És el primer que cal activar després de crear la VPC.

Deixar PubliclyAccessible=true a RDS. Moure-la a una subxarxa privada no n'hi ha prou: si l'atribut continua actiu, RDS retorna una IP pública i l'aplicació deixa de connectar.

No etiquetar la xarxa. Una VPC sense Name i sense Proyecto és un vpc-0a1b2c3d que d'aquí a sis mesos ningú no gosa esborrar. Totes les comandes d'aquesta lliçó porten les cinc etiquetes obligatòries per aquesta raó; a 11-02 veurem el valor econòmic que té.

Deixar IP elàstiques sense associar. Costen encara que no facin res. Revisa-les amb la comanda de la secció de neteja cada vegada que esborris una instància.

Consell d'or: abans de crear ni una sola subxarxa, dibuixa la taula de rangs en un document. Deu minuts de paper estalvien una migració de xarxa.

MercadoFresco vol obrir una VPC de desenvolupament a eu-west-1 i una altra de futura a eu-central-1, i a més connectar l'oficina per VPN. Dissenya el pla d'adreçament complet: rangs que assignes a cada xarxa, justificació, i què passaria si assignessis 10.0.0.0/16 a les tres VPC.

Per a una VPC 10.5.0.0/16 dissenyada amb tres AZ i dues capes (pública i privada), fent servir màscara /22 a les públiques i /20 a les privades: escriu la taula completa de les sis subxarxes amb els seus CIDR sense solapament, indica quantes IP útils té cadascuna i quant espai queda lliure.

El Luis llança una instància a snet-mercadofresco-app-a i no pot executar dnf update. Escriu la seqüència de comprovacions per CLI, en ordre, i què buscar a cadascuna. Considera almenys quatre causes possibles diferents.

Solució 1

Pla d'adreçament, respectant el mapa que ja vam definir:

Amb 10.0.0.0/16 a les tres VPC: cadascuna funcionaria perfectament per separat, i aquest és el perill, perquè el problema no apareix fins mesos després. En intentar el primer peering, AWS rebutja la petició directament: no es poden aparellar VPC amb CIDR solapats. En muntar la VPN amb l'oficina, l'oficina no podria distingir a quina VPC enviar un paquet destinat a 10.0.32.15. L'única solució seria recrear una VPC sencera i migrar-ne tots els recursos, perquè el CIDR principal és immutable.

Solució 2

VPC 10.5.0.0/16 (de 10.5.0.0 a 10.5.255.255). Un /22 són 1.024 adreces (blocs de 4 al tercer octet); un /20 són 4.096 (blocs de 16).

Total assignat: 3.072 + 12.288 = 15.360 adreces. La VPC en té 65.536, així que en queden 50.176 de lliures (des de 10.5.64.0 en endavant), és a dir, un 76 % de l'espai. Detall de disseny: les públiques ocupen de 10.5.0.0 a 10.5.11.255 i les privades comencen a 10.5.16.0 deixant un forat deliberat a 10.5.12.0/22, per poder ampliar la capa pública sense fragmentar el pla.

Solució 3

Què buscar: que existeixi 0.0.0.0/0 amb un NatGatewayId. Si no apareix cap taula, la subxarxa està fent servir la taula principal, que no té ruta de sortida: cal associar-la.

Què buscar: estat available. I comprovar que el seu SubnetId és la subxarxa pública, no la privada. Un NAT en subxarxa privada és la causa clàssica.

Què buscar: GatewayId començant per igw-. Sense això, el NAT tampoc no té sortida.

Què buscar: per defecte tot grup de seguretat permet tota la sortida, però si algú l'ha restringida, dnf no arribarà al repositori. Això ja entra en el terreny de la lliçó 03-02.

Una cinquena causa a descartar: la instància va arrencar abans que existís la ruta del NAT i té la memòria cau de xarxa antiga; n'hi ha prou de reiniciar-la. I una sisena: els Flow Logs mostren REJECT en el trànsit de tornada, cosa que apuntaria a una NACL, que també és matèria de 03-02.

MercadoFresco ja no viu a la xarxa que li va tocar per defecte: viu a vpc-mercadofresco, una xarxa dissenyada. Saps que una VPC és regional i una subxarxa és zonal, que el CIDR principal 10.0.0.0/16 és immutable i per això es tria generós, i que les adreces privades són gratis. Pots llegir una màscara i calcular-ne les IP útils, i saps que AWS reserva cinc adreces a cada subxarxa, entre elles la .1 de l'encaminador i la .2 del resolutor DNS. Has documentat el mapa de rangs de l'empresa perquè 10.0.0.0/16 no xoqui mai amb el 192.168.10.0/24 de l'oficina quan arribi la VPN.

Has construït les sis subxarxes en tres capes i dues zones de disponibilitat, i entens el concepte que sosté tot el mòdul: una subxarxa és pública únicament perquè la seva taula de rutes té un 0.0.0.0/0 apuntant a l'Internet Gateway, no per un ajust ni pel seu nom. Saps que la ruta local és la que permet que la botiga parli amb la base de dades sense configurar res, i que la capa de dades no té cap sortida a internet per disseny: això és defensa en profunditat, no una regla que algú pugui esborrar per error.

Coneixes el NAT Gateway —on es col·loca, per què un per AZ, i que costa uns 35 USD al mes per unitat més 0,048 USD per GB, cosa que el converteix en el recurs més car que has creat fins ara— i les seves alternatives per a un compte d'aprenentatge. Distingeixes IP privada, pública, elàstica i ENI, i saps que una EIP sense associar continua cobrant. Has muntat el punt d'enllaç de passarel·la cap a S3, que és gratuït i treu del NAT tot el trànsit del catàleg de fotos, i saps quan cal un punt d'enllaç d'interfície amb PrivateLink. Has activat enableDnsHostnames, has mogut la base de dades mercadofresco-pedidos a sng-mercadofresco-datos mitjançant instantània i restauració —amb --no-publicly-accessible— i has encès els VPC Flow Logs cap a mercadofresco-registros-web.

Però la xarxa que has construït, ara mateix, no filtra res. La ruta local permet que qualsevol instància de la VPC obri una connexió al port 5432 de la base de dades, i la subxarxa pública accepta el que arribi per l'Internet Gateway. Falta el tallafocs. A la lliçó 03-02, «Grups de seguretat i llistes de control d'accés», muntarem les dues capes de filtratge d'AWS: els grups de seguretat —amb estat i, sobretot, amb la tècnica de referenciar uns grups des d'altres en lloc d'escriure rangs d'IP— i les NACL, sense estat, amb les seves regles numerades i el seu parany dels ports efímers. En acabar, el port 5432 de mercadofresco-pedidos només acceptarà connexions del grup de seguretat de la botiga, i sabràs llegir un REJECT dels Flow Logs que acabes d'encendre per esbrinar exactament quina de les dues capes ha bloquejat un paquet.