View a markdown version of this page

Limitazioni del log di flusso - Amazon Virtual Private Cloud

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Limitazioni del log di flusso

Per utilizzare i log di flusso, occorre considerare le seguenti limitazioni:

  • Dopo aver creato un log di flusso, i dati del log di flusso non verranno visualizzati finché non vi sarà traffico attivo per l’interfaccia di rete, la sottorete o il VPC selezionato.

  • Non è possibile abilitare log di flusso per VPC che sono collegati in peering al VPC a meno che il VPC di peering non si trovi nel proprio account.

  • Dopo aver creato un log di flusso, non è possibile modificarne la configurazione o cambiarne il formato del record. Ad esempio, non è possibile associare un ruolo IAM diverso al log di flusso o aggiungere o rimuovere campi nel record del log di flusso. Invece, è possibile eliminare il log di flusso e crearne uno nuovo con la configurazione richiesta.

  • Se l’interfaccia di rete dispone di più indirizzi IPv4 e il traffico viene inviato a un indirizzo IPv4 privato secondario, il log di flusso visualizza l’indirizzo IPv4 privato principale nel campo dstaddr. Per acquisire l’indirizzo IP di destinazione originale, crea un log di flusso con il campo pkt-dstaddr.

  • Se il traffico viene inviato a un’interfaccia di rete e la destinazione non è uno degli indirizzi IP dell’interfaccia di rete, il log di flusso visualizza l’indirizzo IPv4 privato principale nel campo dstaddr. Per acquisire l’indirizzo IP di destinazione originale, crea un log di flusso con il campo pkt-dstaddr.

  • Se il traffico viene inviato da un'interfaccia di rete e l'origine non è uno degli indirizzi IP dell'interfaccia di rete, il comportamento dipende dalla direzione del flusso. Per un flusso in uscita, il log di flusso visualizza l'indirizzo IPv4 privato primario nel campo. srcaddr Per acquisire l’indirizzo IP di origine originale, crea un log di flusso con il campo pkt-srcaddr.

    Se il record del log riguarda un flusso di ingresso nell’interfaccia di rete, l’IP privato primario dell’interfaccia di rete non verrà visualizzato nel campo srcaddr.

  • Quando l'interfaccia di rete è collegata a un'Nitro-basedistanza, l'intervallo di aggregazione è sempre pari o inferiore a 1 minuto, indipendentemente dall'intervallo di aggregazione massimo specificato.

  • Per i campi pkt-srcaddr e pkt-dstaddr, se la conservazione dell’indirizzo IP del client è abilitata per il livello intermedio, questo campo può mostrare l’IP del client conservato anziché l’indirizzo IP del livello intermedio.

  • Per il campo traffic-path, il valore è lo stesso di quello per i flussi che attraversano le risorse nello stesso VPC e i flussi che attraversano un gateway locale Outpost.

  • Alcuni record del log di flusso sono stati ignorati durante l’intervallo di aggregazione (consulta log-status in Campi disponibili). Ciò può essere causato da un vincolo di AWS capacità interna o da un errore interno. Se si utilizza AWS Cost Explorer per visualizzare gli addebiti dei log di flusso VPC e alcuni log di flusso vengono ignorati durante l'intervallo di aggregazione del log di flusso, il numero di log di flusso riportato in AWS Cost Explorer sarà superiore al numero di log di flusso pubblicati da Amazon VPC.

  • Se utilizzi Blocco dell’accesso pubblico (BPA) VPC:

    • I log di flusso per BPA VPC non includono i record ignorati.

    • I log di flusso per BPA VPC non includono bytes anche se includi il campo bytes nel log di flusso.

  • VPC Flow Logs supporta un massimo di 250 abbonamenti per risorsa per account. Per creare sottoscrizioni aggiuntive su una risorsa che ha raggiunto questo limite, devi prima eliminare le sottoscrizioni esistenti.

I log di flusso non acquisiscono tutto il traffico IP. I seguenti tipi di traffico non vengono registrati:

  • Traffico generato da istanze quando contattano il server Amazon DNS. Se si utilizza il proprio server DNS, tutto il traffico al server DNS viene registrato.

  • Traffico generato da un’istanza Windows per attivazione licenza Windows Amazon.

  • Traffico da e per 169.254.169.254 per metadati istanza.

  • Traffico da e per 169.254.169.123 per Amazon Time Sync Service.

  • Traffico DHCP.

  • Traffico di origine con mirroring. Verrà visualizzato solo il traffico di destinazione con mirroring.

  • Traffico all’indirizzo IP riservato per il router VPC predefinito.

  • Traffico tra un’interfaccia di rete endpoint e un’interfaccia di rete Network Load Balancer.

  • Traffico ARP (Address Resolution Protocol).

  • Traffico su un gateway NAT regionale di breve durata, che viene eliminato pochi minuti dopo la creazione.

Limitazioni specifiche dei campi ECS disponibili nella versione 7:

  • I campi ECS non vengono calcolati se le attività ECS sottostanti non appartengono al proprietario dell’abbonamento al log di flusso.

    Ad esempio, supponiamo di condividere una sottorete (SubnetA) con un altro account (AccountB) e quindi di creare un abbonamento al log di flusso per. SubnetA Se AccountB avvia attività ECS nella sottorete condivisa, l'abbonamento riceve i registri del traffico da tali attività. Tuttavia, i campi ECS per questi registri non vengono calcolati a causa di problemi di sicurezza.

  • Se crei sottoscrizioni ai log di flusso con campi ECS a livello di VPC/Subnet risorsa, tutto il traffico generato per interfacce di rete non ECS verrà distribuito anche per le tue sottoscrizioni. I valori per i campi ECS saranno “-” per il traffico IP non ECS. Ad esempio, disponi di una sottorete (subnet-000000) e crei un abbonamento al log di flusso per questa sottorete con campi ECS (fl-00000000). In subnet-000000, avvii un’istanza EC2 (i-0000000) connessa a Internet e che genera attivamente traffico IP. Puoi anche avviare un’attività ECS (ECS-Task-1) in esecuzione nella stessa sottorete. Poiché sia i-0000000 che ECS-Task-1 generano traffico IP, l’abbonamento al log di flusso fl-00000000 fornirà i log di traffico per entrambe le entità. Tuttavia, solo ECS-Task-1 disporrà dei metadati ECS effettivi per i campi ECS che hai incluso in logFormat. Per il traffico correlato a i-0000000, questi campi avranno il valore di “-”.

  • ecs-container-id e ecs-second-container-id vengono ordinati quando il servizio Log di flusso VPC li riceve dal flusso di eventi ECS. Non è garantito che siano nello stesso ordine in cui li vedi sulla console ECS o nella chiamata API. DescribeTask Se un container entra nello stato STOPPED mentre l’attività è ancora in esecuzione, potrebbe continuare a essere visualizzato nel log.

  • I metadati ECS e i log del traffico IP provengono da due origini diverse. Iniziamo a calcolare il traffico ECS non appena otteniamo tutte le informazioni richieste dalle dipendenze upstream.

    Dopo aver iniziato una nuova attività, iniziamo a calcolare i campi ECS quando sono soddisfatte entrambe le seguenti condizioni: riceviamo il traffico IP per l'interfaccia di rete sottostante e riceviamo l'evento ECS che contiene i metadati per l'attività ECS per indicare che l'attività è ora in esecuzione.

    Dopo aver interrotto un'attività, interrompiamo il calcolo dei campi ECS quando sono soddisfatte entrambe le seguenti condizioni: non riceviamo più il traffico IP per l'interfaccia di rete sottostante (o riceviamo traffico IP ritardato di più di un giorno) e riceviamo l'evento ECS che contiene i metadati per l'attività ECS per indicare che l'attività non è più in esecuzione.

  • Sono supportate solo le attività ECS avviate in modalità di rete awsvpc.

Limitazioni specifiche del campo: encryption-status

  • Lo stato di crittografia può essere «-» (non disponibile) in alcuni flussi, a causa della limitazione di alcuni dispositivi di rete nel segnalare lo stato della crittografia. Gli utenti possono ignorare questi flussi nell'analisi.

  • La visualizzazione come crittografata in modalità monitor non significa che il flusso sarà consentito in modalità di applicazione. Viceversa.

    • Se un flusso è crittografato in modalità monitor, potrebbe non essere conforme in modalità di applicazione:

      • Se il flusso coinvolge un ENI creato da un AWS servizio, il servizio deve supportare i controlli di crittografia.

      • Se il flusso passa attraverso il peering VPC, il VPC peering potrebbe non forzare i controlli di crittografia.

    • Se un flusso non è crittografato in modalità monitor, potrebbe comunque essere conforme in modalità di applicazione, dato che il servizio correlato al flusso viene aggiunto come esclusione.

Limitazioni specifiche dei campi Amazon EC2 Tags di Flow Logs disponibili nella versione 11:

  • I campi dei tag non vengono calcolati se i tag su una risorsa non sono di proprietà del proprietario dell'abbonamento al flow log.

    Ad esempio, supponiamo di condividere una sottorete (SubnetA) con un altro account (AccountB) e quindi di creare una sottoscrizione al log di flusso SubnetA con un campo tag sulle interfacce di rete. Se AccountB avvia un'interfaccia di rete con tag con la chiave che hai configurato, l'abbonamento riceve i log del traffico per l'interfaccia di rete avviata da, ma i campi dei tag configurati dall'AccountBabbonamento non vengono calcolati per motivi di sicurezza. Se lo desideri, puoi contrassegnare l'interfaccia di rete avviata da per visualizzarne i tag. AccountB

  • Se crei sottoscrizioni ai log di flusso con campi Tag a livello di VPC/Subnet risorsa, il traffico generato per le interfacce di rete senza tag verrà recapitato anche per i tuoi abbonamenti. I valori per i campi Tag saranno «-» per le risorse senza tag.

  • I gruppi Auto Scaling non saranno in grado di visualizzare alcun tag se sono denominati «-» poiché si tratta di un carattere riservato per indicare missing/no un valore.

  • La creazione di qualsiasi abbonamento Flow Logs con campi Tags comporterà la creazione di alcune risorse per conto del cliente. Per utilizzare gli aggiornamenti dei valori dei tag, verranno create delle regole EventBridge gestite per inviare le modifiche ai tag al servizio Flow Logs. Queste regole EventBridge gestite verranno eliminate automaticamente se tutte le sottoscrizioni con campi Tag vengono eliminate. Non eliminare manualmente queste regole EventBridge gestite. Ciò comporterà notevoli ritardi nell'aggiornamento dei valori dei tag. Per controllare questa situazione creation/cleanup e fornire l'accesso ai valori dei tag, nel tuo account verrà creato un Service Linked Role. Per ulteriori dettagli, consulta Utilizzo di ruoli collegati ai servizi per i log di flusso VPC.

  • A causa dei vincoli di analisi di Amazon CloudWatch Logs e Athena, tutti i caratteri speciali nei valori dei tag verranno codificati utilizzando la codifica percentuale. UTF-8 Questo può essere decodificato in modo nativo in Athena utilizzando url_decode o può essere decodificato da qualsiasi decodificatore URL o URI.

  • Per la prima ora dopo la creazione di un nuovo abbonamento, i valori dei tag potrebbero mancare o essere imprecisi. Dopo questa prima ora, i valori dei tag saranno in grado di riflettere accuratamente i valori delle risorse taggate con una granularità di 1 minuto.

  • Se vengono apportate più modifiche ai tag sulla stessa risorsa nello stesso secondo, è possibile che gli aggiornamenti vadano persi, con conseguenti valori di tag obsoleti fino a un'ora.

  • Per i campi dei tag di gruppo Auto Scaling, devi avere almeno un CloudTrail percorso abilitato nel tuo account. Senza un percorso abilitato, i valori dei tag di gruppo Auto Scaling potrebbero essere obsoleti o imprecisi.

Limitazioni specifiche dei campi: next-hop-

  • I campi dell'hop successivo non vengono calcolati se l'interfaccia di rete dell'hop successivo non è di proprietà del proprietario dell'abbonamento al log di flusso, ad eccezione next-hop-az-id di.

  • I campi dell'hop successivo non sono disponibili se l'hop successivo non dispone di un'interfaccia di rete (ad esempio, traffico verso Internet gateway).

  • I campi next hop non sono disponibili per il traffico interregionale.

  • I campi next hop non sono disponibili per il traffico in ingresso proveniente da alcuni servizi di rete (ad esempio, transit gateway e Network Load Balancer).

  • Se il traffico passa attraverso un middlebox (ad esempio, transit gateway o Network Load Balancer), l'interfaccia di rete dell'hop successivo è l'interfaccia associata al middlebox (come l'allegato del gateway di transito), non la destinazione finale del traffico