Flow Logs på VPC-, subnet- och ENI-nivå

Du kan aktivera Flow Logs på tre nivåer: för hela VPC, ett enskilt subnät eller ett enda elastic network interface (ENI). Nivån du väljer avgör hur mycket trafik som fångas och var insynen fokuseras. Genom att välja rätt omfång balanserar du täckning mot volym och kostnad.

En flow log på VPC-nivå fångar trafik för varje nätverksgränssnitt i varje subnät i denna VPC, inklusive gränssnitt som skapas senare. Detta ger den bredaste täckningen och är enklast att hantera, eftersom en enda konfiguration omfattar hela VPC:n. Det är det vanliga valet för heltäckande säkerhetsövervakning.

En flow log på subnätsnivå fångar alla gränssnitt inom ett subnät. Det är användbart när du vill ha extra detaljrikedom för ett känsligt skikt, till exempel ett databassubnät, utan att logga hela VPC:n. Volymen minskar samtidigt som du behåller full insyn i den delen av nätverket.

En flow log på ENI-nivå riktas mot ett enda nätverksgränssnitt och fångar endast trafik för den resursen. Detta är det mest fokuserade omfånget och passar för djupgående övervakning av en specifik värdefull instans eller för en utredning där du vill isolera anslutningarna för en arbetsbelastning.

Nivåerna ersätter inte varandra utan samexisterar. Nya gränssnitt i en logg på VPC-nivå inkluderas automatiskt när de tillkommer. Du kan lägga en mer detaljerad logg på subnäts- eller ENI-nivå ovanpå en VPC-logg om du vill ha både bred täckning och ett fokuserat anpassat format för ett område.

För fullständig säkerhetsinsyn är en logg på VPC-nivå det säkraste standardvalet, eftersom inget gränssnitt lämnas oövervakat, inte ens sådana som skapas efter konfigurationen. Omfång på subnäts- och ENI-nivå är kompletterande verktyg för extra fokus, inte ersättningar för bred täckning. På provet är VPC-nivå det föredragna svaret när målet är "övervaka all trafik".

Flow Log-volymen påverkar kostnad och lagring. Om du bara behöver insyn i ett bullrigt eller känsligt skikt fångar en logg på subnäts- eller ENI-nivå betydligt mindre data än loggning av hela VPC:n. När budget eller loggvolym är begränsningen är det genom att minska omfånget du kan påverka situationen.

Varje flow log kan ha en egen destination och ett eget format. Du kan till exempel skicka en logg på VPC-nivå i standardformat till S3 för arkivering, medan en logg på subnätsnivå för databasskiktet använder ett innehållsrikt anpassat format som strömmas till CloudWatch för aviseringar i realtid. Genom att blanda omfång kan du anpassa insynen exakt.

I en miljö med flera konton kan du inte aktivera Flow Logs en gång för hela organisationen, men du kan framtvinga dem med AWS Config rules eller Control Tower guardrails som flaggar varje VPC där Flow Logs saknas. Då uppfyller varje konto den grundläggande nivån för insyn, i stället för att du behöver lita på att varje team kommer ihåg det.

För att publicera till CloudWatch Logs behöver Flow Logs en IAM-roll som ger behörighet att skriva till logggruppen. För publicering till S3 måste bucket-policyn tillåta att Flow Logs-leveranstjänsten skriver. Att få dessa behörigheter rätt är en vanlig fallgrop vid konfiguration, eftersom en saknad roll kan avbryta leveransen utan tydlig felindikering.

Ett bra mönster är en logg på VPC-nivå till S3 för billig och fullständig arkivering, kompletterad med riktade loggar på subnäts- eller ENI-nivå till CloudWatch för de skikt som är viktigast. Då får du både en fullständig historisk dokumentation och snabba aviseringar där de behövs, samtidigt som kostnaden för den stora datamängden hålls under kontroll.

Flow Logs kan begränsas till en VPC, ett subnät eller ett enda ENI, och dessa omfång samexisterar. VPC-nivå ger fullständig täckning, inklusive framtida gränssnitt, och är standardvalet för full insyn. Omfång på subnäts- och ENI-nivå minskar volymen och fokuserar på känsliga skikt. Varje logg har en egen destination och ett eget format, och korrekta IAM-/bucket-behörigheter krävs för leveransen.