Flow Logs på VPC-, subnet- og ENI-niveau

Du kan aktivere Flow Logs på tre niveauer: hele VPC'en, ét subnet eller én elastic network interface (ENI). Det valgte niveau bestemmer, hvor meget trafik der registreres, og hvor synligheden fokuseres. Det rigtige omfang skaber balance mellem dækning, datamængde og omkostninger.

Et flowlog på VPC-niveau registrerer trafik for alle netværksinterfaces i alle subnets i den pågældende VPC, også interfaces, der oprettes senere. Det giver den bredeste dækning og er nemmest at administrere, fordi én konfiguration dækker hele VPC'en. Det er normalt det foretrukne valg til omfattende sikkerhedsovervågning.

Et flowlog på subnetniveau registrerer alle interfaces i ét subnet. Det er nyttigt, når du ønsker ekstra detaljer om et følsomt lag, f.eks. et databasesubnet, uden at logge hele VPC'en. Det begrænser datamængden, samtidig med at du bevarer fuld synlighed i denne del af netværket.

Et flowlog på ENI-niveau målrettes ét netværksinterface og registrerer kun trafik for denne ene ressource. Det er det mest fokuserede omfang og er ideelt til detaljeret overvågning af en bestemt værdifuld instans eller til en undersøgelse, hvor du vil isolere forbindelserne for én arbejdsbelastning.

Niveauerne tilsidesætter ikke hinanden; de sameksisterer. Nye interfaces i et flowlog på VPC-niveau inkluderes automatisk, når de oprettes. Du kan lægge et mere detaljeret subnet- eller ENI-log oven på et VPC-log, hvis du både ønsker bred dækning og et fokuseret brugerdefineret format for ét område.

Til fuld sikkerhedssynlighed er et VPC-log på VPC-niveau det sikreste standardvalg, fordi ingen interfaces forbliver uovervågede, heller ikke dem, der oprettes efter opsætningen. Subnet- og ENI-omfang er supplerende værktøjer til ekstra fokus, ikke erstatninger for bred dækning. Eksamen foretrækker VPC-niveau, når målet er "overvåg al trafik".

Mængden af Flow Logs driver omkostningerne og lagerforbruget. Hvis du kun har brug for synlighed i ét støjende eller følsomt lag, registrerer et subnet- eller ENI-log langt færre data end logging af hele VPC'en. Når budgettet eller logmængden er begrænsningen, er en indsnævring af omfanget det håndtag, du skal bruge.

Hvert flowlog kan have sin egen destination og sit eget format. Du kan f.eks. sende et flowlog på VPC-niveau i standardformat til S3 til arkivering, mens et subnetlog for dit databaselag bruger et omfattende brugerdefineret format, der streames til CloudWatch til alarmering i realtid. Ved at blande omfang kan du tilpasse synligheden præcist.

I en opsætning med flere konti kan du ikke aktivere Flow Logs én gang for hele organisationen, men du kan håndhæve dem med AWS Config-regler eller Control Tower-guardrails, der markerer alle VPC'er, som mangler Flow Logs. Så sikrer du, at alle konti opfylder grundkravet til synlighed, i stedet for at stole på, at hvert team husker det.

For at publicere til CloudWatch Logs skal Flow Logs bruge en IAM-rolle, der giver tilladelse til at skrive til loggruppen. For at publicere til S3 skal bucketpolitikken tillade leveringstjenesten for Flow Logs at skrive. Korrekte tilladelser er en almindelig faldgrube i opsætningen, fordi en manglende rolle ubemærket får leveringen til at gå i stå.

Et stærkt mønster er et flowlog på VPC-niveau til S3 til billig, komplet arkivering kombineret med målrettede subnet- eller ENI-logs til CloudWatch for de lag, du interesserer dig mest for. Så får du både en komplet historisk registrering og hurtig alarmering dér, hvor det betyder mest, samtidig med at du begrænser omkostningerne ved de store datamængder.

Flow Logs kan afgrænses til en VPC, et subnet eller én ENI, og disse omfang sameksisterer. VPC-niveau giver fuld dækning, herunder fremtidige interfaces, og er standardvalget til fuld synlighed. Subnet- og ENI-omfang reducerer datamængden og fokuserer på følsomme lag. Hvert log har sin egen destination og sit eget format, og korrekte IAM-/bucket-tilladelser er nødvendige for levering.