# VPC Flow Logs

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/vpc-flow-logs

## Quick definition

VPC Flow Logs are like a security camera for your cloud network. They record details about every packet that enters or leaves your virtual network. You can use these records to see who is talking to whom, spot unusual traffic, and troubleshoot connectivity problems.

## Simple meaning

Imagine you own a busy apartment building with a single entrance. You want to know exactly who comes in, who leaves, when they do it, and whether they were allowed in. A security guard at the door could log every person, noting their ID, the time they entered or exited, and whether they had a keycard. VPC Flow Logs work the same way for your cloud network. They are a feature in cloud computing platforms like Amazon Web Services (AWS) that automatically records information about every network packet that flows through a Virtual Private Cloud (VPC). A VPC is essentially your own private section of the cloud, a virtual network where you run your servers and applications. Every time a piece of data travels from one server to another, or from a server to the internet, Flow Logs capture details about that communication. The log entries include the source IP address (where the traffic came from), the destination IP address (where it is going), the port numbers used (like a specific door for a specific service), the protocol (the language the data speaks, such as TCP or UDP), and whether the traffic was accepted or rejected by your security rules. You do not have to install any software or change your application. You simply enable the feature on a network interface, a subnet (a smaller section of your network), or the entire VPC. The logs are then sent to a storage service like Amazon S3 or a log management service like CloudWatch Logs. This makes it incredibly easy to monitor network traffic without slowing down your systems. The information helps you answer questions like: Is my web server receiving too many requests from a suspicious country? Are my database servers talking only to the application servers they should? Why is my application timing out? By looking at the logs, you can see if the traffic was blocked by security groups or network access control lists. In short, VPC Flow Logs give you a simple, detailed history of all the communications happening inside your cloud network, helping you keep it secure and running smoothly.

You do not have to be a network engineer to understand the value. If you have ever wondered why a website is slow, or why a connection fails, Flow Logs can show you exactly what happened at the network level. They are a foundational tool for anyone learning cloud networking, especially for IT certification exams that cover security, troubleshooting, and monitoring.

One common everyday analogy is a toll booth on a highway. Every car that passes through is recorded: its license plate (IP address), the time it entered and exited, and the lane it used (port). If a car tries to take an exit that is closed, the system logs a rejection. Flow Logs do the same thing for data packets traveling across your cloud network.

## Technical definition

VPC Flow Logs is a feature of Amazon Virtual Private Cloud (VPC) that enables you to capture information about the IP traffic going to and from network interfaces in your VPC. Flow log data can be published to Amazon CloudWatch Logs or Amazon Simple Storage Service (S3). After you create a flow log, you can view and retrieve its data in the chosen destination.

The data captured in each flow log record includes the following fields: version (the flow log version), account-id, interface-id (the elastic network interface), srcaddr (source IPv4 or IPv6 address), dstaddr (destination address), srcport (source port), dstport (destination port), protocol (IANA protocol number, e.g., 6 for TCP, 17 for UDP), packets (number of packets transferred), bytes (number of bytes transferred), start (timestamp of the start of the aggregation interval), end (timestamp of the end), action (ACCEPT or REJECT, based on the security group and network ACL evaluation), and log-status (OK, NODATA, or SKIPDATA). The aggregation interval is typically 10 minutes, but you can also set it to 1 minute for VPC Flow Logs published to CloudWatch Logs.

Flow logs are not real-time. They are aggregated and published periodically. They can be created at three levels: VPC, subnet, or network interface. When you create a flow log at the VPC or subnet level, it automatically captures traffic for all network interfaces within that scope. However, you cannot tag a flow log itself; you tag the resources that generate the flow logs.

Important implementation details: Flow logs do not capture all IP traffic. They do not capture traffic to the Amazon DNS server, traffic to the Amazon Windows license activation server, traffic to the Amazon Time Sync Service (169.254.169.123), traffic to the Amazon S3 endpoint (when using gateway endpoint), or DHCP traffic. Also, traffic to the reserved IP address of the VPC network router (the .1 address) is not logged. Flow logs cannot be enabled on network interfaces that are part of a VPC peering connection if the interfaces are in a different account, unless you are the owner of both accounts and have proper permissions.

Flow logs are a critical tool for security analysis, network performance monitoring, and troubleshooting connectivity issues. They provide a record of the traffic that is evaluated by security group and network ACL rules. For example, if an application is unable to connect to a database, you can analyze the flow logs to see if the traffic was allowed or denied, and at which point (security group vs. network ACL). This helps identify misconfigured rules.

In an enterprise environment, flow logs are often used for compliance audits. They can be integrated with AWS CloudTrail for a complete audit trail of API calls and network traffic. Third-party security tools like Splunk or Datadog can consume flow log data for anomaly detection. When working with AWS Organizations, you can centrally manage flow logs across multiple accounts.

From a protocol perspective, flow logs cover IPv4 and IPv6 traffic. They support TCP, UDP, ICMP, and other protocols. The action field indicates whether the traffic was permitted or denied. A common exam scenario involves distinguishing between the evaluation of security groups (stateful) and network ACLs (stateless). Flow logs will show ACCEPT or REJECT based on the combined evaluation of both. Understanding this interaction is essential for designing secure and functional cloud networks.

## Real-life example

Think of VPC Flow Logs like a doorbell camera system for your house combined with a package delivery log. Your house is the VPC. The doors and windows represent the network interfaces, entry and exit points for data. The doorbell camera records every time someone rings the bell, walks up the steps, or walks away. It records the time, the person's face (source IP), and whether they were allowed to enter (action = ACCEPT or REJECT). The package delivery log records every package that arrives, including the sender, the carrier, and whether it was handed to a resident or left on the porch.

Now imagine you are expecting a package from a friend. You check your doorbell camera footage and see a delivery person walk up, leave a box, and walk away. But the box is missing when you get home. You check the flow log, you see the delivery was logged, but there is no record of someone taking it. That tells you the package was probably stolen. In cloud terms, you are checking if a connection was initiated and if the return traffic was allowed. If the logs show a REJECT for the return traffic, you know a security rule is blocking the response.

Another analogy: a traffic camera at a border crossing. Every car is recorded with its license plate, time of entry, and time of exit. If a car enters but never exits, you know something happened inside the country. Similarly, if a flow log shows a lot of inbound traffic but no outbound responses, you might have a server that is failing to respond due to a misconfigured firewall or a crashed application.

These analogies help map to the IT concept: you are capturing metadata about every network conversation. You are not capturing the content of the packets (like the actual data in an email or a web page). You are only capturing the header information, the source, destination, port, protocol, and whether it was allowed. This is exactly like a camera recording a car's license plate but not what is inside the car.

## Why it matters

VPC Flow Logs are a foundational tool for network security, troubleshooting, and compliance in the cloud. In a practical IT context, they are often the first place you go when something goes wrong with connectivity. Imagine you deploy a web application, but users complain they cannot reach it. You check the security groups and network ACLs, and they seem correct. Without flow logs, you are guessing. With flow logs, you can pull the records for the web server's network interface and see if the traffic is arriving (ACCEPT) or being denied (REJECT). If it is accepted, the problem is likely in the application itself. If it is rejected, you know which security layer is blocking it.

Flow logs also matter for security. They provide an audit trail of all network connections. If a security incident occurs, such as a data breach or a malware infection, flow logs can help forensic investigators trace the attack. They can see which IP addresses communicated with compromised servers, at what time, and on which ports. This helps identify the scope of the breach and the method of entry. Many compliance frameworks, such as PCI DSS, require network monitoring and logging. Flow logs help meet those requirements without deploying additional hardware.

For IT professionals, understanding flow logs is essential when you move from on-premises networking to cloud networking. In a traditional data center, you might use port mirroring or netflow collectors. In the cloud, you have no physical access to switches. Flow logs replace those tools with a software-defined logging service. You can aggregate flow logs from hundreds of accounts into a central data lake for analysis.

flow logs help with cost optimization. Unusual traffic patterns might indicate a misconfigured load balancer or an open port that is being scanned by bots. By analyzing flow logs, you can refine security rules and reduce unnecessary data transfer costs. For instance, if you see many rejected connection attempts to a port that should not be open, you can tighten the security group to drop the traffic at the network ACL level, reducing the load on your instances.

In team environments, flow logs are often used to enforce the principle of least privilege. You can verify that only authorized services communicate with each other. For example, you expect only the web servers to talk to the application servers on port 8080. Flow logs can confirm that no other traffic is passing between those tiers. If you see traffic on port 22 (SSH) between tiers, you know someone has bypassed the bastion host, which is a security violation.

## Why it matters in exams

VPC Flow Logs are a recurring topic in several major cloud certification exams, especially those from AWS. The AWS Certified Solutions Architect Associate (SAA-C03) exam frequently includes questions about flow logs in the context of security, troubleshooting, and monitoring. You might see a scenario where an application is unreachable, and you must decide whether to enable flow logs or analyze existing logs to find the root cause. The exam expects you to know the difference between security group evaluation (stateful) and network ACL evaluation (stateless) and how flow logs reflect the combined outcome.

For the AWS Certified SysOps Administrator Associate (SOA-C02) exam, flow logs are tested more operationally. You might be asked to configure flow logs to capture traffic for a specific subnet, or to publish logs to CloudWatch Logs for real-time analysis. SysOps questions often involve troubleshooting connectivity issues by interpreting flow log records. You need to know the meaning of each field, especially the action field (ACCEPT vs REJECT) and the log-status field (OK, NODATA, SKIPDATA).

The AWS Certified Security Specialty (SCS-C02) exam dives deeper. Questions might involve using flow logs for forensic analysis after a security incident. You might be asked to query flow logs in S3 using Amazon Athena or to detect anomalous traffic patterns. You also need to understand that flow logs do not capture all traffic (e.g., DNS queries to the Amazon DNS server, DHCP traffic) and that you cannot capture traffic on certain reserved IP addresses. The security exam may also test integration with AWS Config and AWS CloudTrail for continuous compliance.

Even non-AWS certifications, such as the CompTIA Cloud+ or the Google Cloud Professional Cloud Architect, have concepts similar to VPC Flow Logs (Google VPC Flow Logs, Azure Network Watcher). While the term VPC Flow Logs is specific to AWS, the underlying idea of capturing IP traffic metadata is universal. For general IT certification exams that cover networking, you might be asked to explain the purpose of flow logs as a network monitoring tool.

Question types often include: multiple-choice scenario questions where you choose the best monitoring solution for a given problem; drag-and-drop questions where you match flow log fields to their definitions; and order-of-operations questions about enabling flow logs on a VPC. You may also see comparison questions: How are flow logs different from AWS CloudTrail? How are they different from AWS Config? The answer is that CloudTrail logs API calls, Config records resource configuration changes, and flow logs record network traffic metadata.

A common exam trap is the assumption that flow logs capture all traffic. They do not. Exams test your knowledge of the excluded traffic types. Another trap is confusing flow logs with server logs. Flow logs are captured at the hypervisor level, not inside the virtual machine. You cannot turn off flow logs from within the OS. You must use the AWS API or console.

To do well on exam questions, memorize the three levels (VPC, subnet, network interface) and the two destinations (CloudWatch Logs, S3). Also remember that flow logs are not real-time. They are aggregated and pushed at intervals (1 minute or 10 minutes). If a question asks for real-time monitoring, the answer is likely VPC Traffic Mirroring, not flow logs.

## How it appears in exam questions

VPC Flow Logs appear in certification exam questions in several distinct patterns. The most common is the scenario-based question where a developer or administrator reports that an application cannot connect to a database. The question will describe the security group and network ACL configurations, and then ask what tool can be used to determine why the traffic is being denied. The correct answer will be to enable VPC Flow Logs on the network interface of the database server and then analyze the log records for REJECT entries. A distractor might be AWS CloudTrail, which logs API calls, not network traffic.

Another common pattern is the configuration type question. The question might say: A company wants to log all traffic to a specific subnet to meet compliance requirements. Which action should be taken? The answer is to create a flow log at the subnet level and specify a destination (CloudWatch Logs or S3). You may need to choose between publishing to CloudWatch Logs for real-time analysis or to S3 for long-term storage. The question might also include an IAM policy or a bucket policy that must be correctly configured.

Troubleshooting questions often present a flow log record and ask you to interpret it. For example: The following flow log record shows TCP traffic from 10.0.1.5:443 to 10.0.2.10:5432 with action REJECT. What does this indicate? The answer: The traffic from the source to the destination was blocked by either a security group or a network ACL. You might need to deduce which security layer caused the reject based on the inbound vs outbound rules described in the scenario.

Exam questions also test your understanding of what traffic is not captured. For example: Which of the following traffic types is NOT captured by VPC Flow Logs? Answers might include traffic to the Amazon Time Sync Service, DHCP traffic, and traffic to the VPC router. You must know that traffic to the Amazon DNS server (169.254.169.253) is also excluded.

A more advanced question might integrate flow logs with other services. For instance: A security team must analyze millions of flow log records to detect a DDoS attack. Which solution is most cost-effective? The answer: Use Amazon Athena to query flow logs stored in S3. Another possible question: How can you monitor flow logs in real time? The answer: Publish flow logs to CloudWatch Logs and set up metric filters and alarms.

You may also see comparison questions: What is the difference between VPC Flow Logs and VPC Traffic Mirroring? The key difference is that flow logs capture metadata (headers) while Traffic Mirroring captures the full packet content for deep packet inspection.

Finally, some questions test the stateful vs stateless interaction. They might present a scenario where inbound traffic is accepted by the security group, but outbound traffic is denied by the network ACL. The question asks: What will the flow log record show for the inbound traffic? The answer: ACCEPT, because the security group accepted it. But the return traffic will show REJECT because the network ACL is stateless and requires an explicit outbound rule. You must understand that flow logs log each direction independently.

## Example scenario

Scenario: You are a junior cloud administrator at a company that runs an e-commerce website on AWS. The application consists of web servers in a public subnet and database servers in a private subnet. Users report that the website loads slowly sometimes, and occasionally they get a time-out error. The senior administrator asks you to investigate whether the problem is network-related.

You decide to enable VPC Flow Logs on the network interface of one web server and the network interface of one database server. You create a flow log for the web server's interface and send the logs to CloudWatch Logs. After a few minutes, you look at the log records. You see that many connections from the web server to the database server on port 3306 (MySQL) are being logged with action ACCEPT. So the database is reachable. However, you notice that a few connections from the web server to an external IP address on port 443 (HTTPS) are showing action REJECT. That is strange. You check the security group rules for the web server. You see that outbound HTTPS traffic is allowed to any destination. But wait, the network ACL for the public subnet has a rule that denies all outbound traffic to a specific IP range by default. You check and see that the external IP address falls into that range. The network ACL is blocking the outbound traffic from the web server to that external service, which might be a payment gateway or a caching service. This explains the intermittent time-outs: sometimes the web server needs to contact that external service, but the network ACL drops the request.

You recommend modifying the network ACL to allow outbound traffic to that IP range on port 443. After the change, you check the flow logs again and see that the previously rejected connections are now being accepted. The time-out errors disappear. The senior administrator is impressed that you used flow logs to pinpoint the exact rule causing the issue.

This scenario shows how VPC Flow Logs help you isolate problems that are not obvious from just looking at security groups. Without flow logs, you might have spent hours checking the application code or restarting services, not realizing that a network ACL was silently dropping outbound traffic. Flow logs provide the concrete evidence you need to identify and fix network configuration errors quickly.

## Common mistakes

- **Mistake:** Believing flow logs capture all network traffic, including traffic to the AWS DNS server and DHCP.
  - Why it is wrong: Flow logs explicitly exclude traffic to the Amazon DNS server, the Amazon Time Sync Service, DHCP traffic, and traffic to the VPC reserved IP addresses. Assuming they capture everything leads to missing data and incorrect troubleshooting.
  - Fix: Memorize the list of excluded traffic types. If a question mentions traffic that seems internal or reserved, check if it falls into the excluded category before concluding that flow logs would capture it.
- **Mistake:** Thinking that a flow log with action REJECT means the packet was dropped by a security group.
  - Why it is wrong: The REJECT action means the traffic was denied by either a security group, a network ACL, or both. You cannot tell from the flow log alone which layer rejected it. You must examine the security group and network ACL rules separately.
  - Fix: When you see REJECT in a flow log, investigate both security group and network ACL configurations. Use the log's source and destination IP to determine which direction the traffic was heading and what rules apply.
- **Mistake:** Assuming flow logs are real-time and can be used for live troubleshooting.
  - Why it is wrong: Flow logs are aggregated and published at intervals of 1 minute or 10 minutes. There is inherent latency. For real-time packet analysis, you need VPC Traffic Mirroring or third-party agents.
  - Fix: Use flow logs for historical analysis and pattern detection. For real-time troubleshooting, consider enabling detailed monitoring on a network interface or using traffic mirroring.
- **Mistake:** Creating a flow log at the VPC level and expecting it to capture traffic for a network interface in a peered VPC in another account.
  - Why it is wrong: Flow logs capture traffic only for network interfaces within the scope of the VPC where they are created. For peered VPCs with different accounts, you must create flow logs in each account separately. Cross-account flow log aggregation is possible but requires additional configuration.
  - Fix: Create flow logs in each VPC that you need to monitor. Use a central logging account with a subscription filter or a cross-account role to aggregate the logs in one place.
- **Mistake:** Thinking that the 'bytes' field in flow logs represents the number of packets, or vice versa.
  - Why it is wrong: The 'packets' field counts the number of packets transferred during the aggregation interval. The 'bytes' field counts the total number of bytes transferred. Mixing these up leads to incorrect traffic analysis.
  - Fix: Remember: packets = count, bytes = total data volume. For traffic volume analysis, use bytes. For packet-level analysis, use packets.

## Exam trap

{"trap":"A question states that an application is not responding, and flow logs show ACCEPT for both inbound and outbound traffic. The candidate assumes the problem is not network-related and looks for application issues, but the real issue is that the flow log is not capturing traffic to the application's specific port because the security group allows all traffic, but the application is listening on a port that is not the default port shown in the log.","why_learners_choose_it":"Learners often see ACCEPT and immediately conclude the network is fine. They forget that flow logs capture metadata only, they do not indicate whether the application is healthy or if the correct port is being used. They also overlook the fact that the log might not show the particular connection because it was not logged in the aggregation window yet.","how_to_avoid_it":"Always verify that the flow log is actually capturing the specific traffic in question. Check the aggregation interval. Also remember that flow logs show the evaluated result of security rules, they do not guarantee that the application is running or that the traffic reached the intended process on the server. Always correlate flow logs with application logs and server metrics."}

## Commonly confused with

- **VPC Flow Logs vs AWS CloudTrail:** CloudTrail records API calls made to the AWS account, such as launching an EC2 instance or creating a security group. VPC Flow Logs record network traffic metadata, not API activity. CloudTrail is about who did what, while Flow Logs is about what data moved where. (Example: If you want to know who changed a security group rule, use CloudTrail. If you want to know if a specific IP address is connecting to your server, use VPC Flow Logs.)
- **VPC Flow Logs vs AWS Config:** AWS Config continuously records resource configuration changes and evaluates them against desired rules. VPC Flow Logs do not record configuration changes. Config tells you when a security group rule was added; Flow Logs tells you what traffic hit that group before and after the change. (Example: Use Config to detect if a security group becomes too permissive. Use Flow Logs to see the actual traffic that was allowed or blocked by that security group.)
- **VPC Flow Logs vs VPC Traffic Mirroring:** VPC Traffic Mirroring captures the entire packet contents, including payload, for deep packet inspection. VPC Flow Logs only capture packet headers (metadata). Traffic Mirroring is used for security analysis and intrusion detection systems, while Flow Logs are for monitoring and troubleshooting. (Example: If you need to see the actual data inside a network flow (e.g., a SQL query), use Traffic Mirroring. If you only need to know that traffic occurred on port 3306, use VPC Flow Logs.)
- **VPC Flow Logs vs Network Access Control List (NACL) Logs:** AWS does not have a separate service called NACL logs. The logging of NACL evaluations is done through VPC Flow Logs. Some learners confuse the concept of a NACL with a separate logging feature. Flow Logs log the combined outcome of both security groups and NACLs. (Example: When you see a REJECT in a flow log, it could be due to a NACL rule. But there is no separate NACL log to check. You must look at the NACL configuration to find the blocking rule.)

## Step-by-step breakdown

1. **Enable VPC Flow Logs** — You enable flow logs at the VPC, subnet, or network interface level via the AWS Management Console, CLI, or API. You must specify a destination for the logs, either Amazon CloudWatch Logs or Amazon S3. You also define the capture interval (1 or 10 minutes) and the traffic type (ALL, ACCEPT, or REJECT). A service-linked IAM role is created automatically to allow the flow log service to publish logs to the chosen destination.
2. **Traffic Evaluation Begins** — Once enabled, the hypervisor monitoring the network interface starts collecting metadata about each packet that is processed. The hypervisor evaluates the packet against the security group (stateful) and network ACL (stateless) rules. It records the source and destination IP addresses, ports, protocol, and the result of the evaluation (ACCEPT or REJECT). The hypervisor does not alter or inspect the packet payload.
3. **Aggregation Period** — The hypervisor aggregates the captures over the chosen interval (usually 10 minutes). It counts the number of packets and bytes for each unique flow. A flow is defined by a tuple of source IP, destination IP, source port, destination port, and protocol. All packets that match the same tuple in the same direction within the interval are counted together into one log record.
4. **Publish to Destination** — At the end of each aggregation interval, the flow log service publishes a batch of log records to the configured destination. If using CloudWatch Logs, the records are sent as log events to a log group. If using S3, the records are written as a new object in the specified S3 bucket. The log file can be plain text with space-separated fields or in Apache Parquet format for efficient querying.
5. **Analyze Logs** — Once the logs are available, you can analyze them using CloudWatch Logs Insights, Amazon Athena, or third-party tools. You can query for specific IP addresses, ports, or action types. For example, you might search for all records with action REJECT to find blocked traffic, or group by source IP to identify a scanning host. This analysis helps you understand traffic patterns, debug connectivity issues, and detect security threats.
6. **Retention and Archiving** — Flow logs stored in CloudWatch Logs have a configurable retention policy. You can choose to keep them for a specific number of days or indefinitely. Logs stored in S3 can be managed with lifecycle policies to transition to cheaper storage classes like S3 Glacier for long-term compliance. You can also set up cross-account log delivery for centralized visibility.

## Practical mini-lesson

VPC Flow Logs are one of the most practical tools a cloud administrator can master. They give you visibility into the network traffic that your security policies are either allowing or blocking. To use them effectively, you need to understand the data they produce and how to interpret it.

First, you need to decide at which scope to enable flow logs. If you are troubleshooting a specific EC2 instance, enable flow logs on its network interface. If you are auditing an entire application tier, enable at the subnet level. If you need a full picture of all traffic in the VPC, enable at the VPC level. Remember that flow logs at a higher scope log all traffic for all interfaces in that scope. There is no extra cost for using a higher scope-you are just aggregating the same data. Still, you pay for the log storage, so consider the volume.

Next, choose the destination. CloudWatch Logs is better for real-time monitoring and alerts. You can create metric filters to trigger alarms on specific patterns, like a spike in REJECT actions. S3 is better for long-term storage and large-scale analysis using Athena or Amazon QuickSight. Many enterprises use both: CloudWatch Logs for operational monitoring and S3 for compliance and forensic analysis.

The traffic type field is important. You can choose to log only ACCEPT, only REJECT, or ALL traffic. For security monitoring, logging only REJECT is cost-efficient because it reduces log volume while still capturing what might be an attack. For full troubleshooting, log ALL. However, be aware that logging all traffic can generate massive amounts of data quickly, especially for high-throughput instances. Always estimate the log volume before enabling.

Now, interpreting the logs. A common scenario: you see a flow log record with action REJECT for traffic from your web server (10.0.1.10) to your database (10.0.2.20) on port 3306. You check the security group for the database: it allows inbound traffic from the web server security group on port 3306. So why is it rejected? You then check the network ACL for the private subnet where the database lives. The outbound rule on that NACL allows all traffic for ephemeral ports, but the inbound rule on the NACL must allow the incoming traffic. In this example, the inbound NACL rule might only allow traffic from a specific range that does not include the web server's subnet. That is why the traffic is rejected. The flow log record gave you the clue; you just have to trace through both layers.

Another practical point: flow logs can help you identify if a security group rule is too permissive. If you see a lot of traffic to a port that should not be receiving traffic, you know that the security group allows it. You can then tighten the rule. For example, you might see SSH traffic (port 22) from an IP address that is not in your approved list. That indicates your security group allows SSH from a broader range than intended.

One thing that often goes wrong is that people forget to set up the required IAM role. When you create a flow log via the console, AWS creates the role for you automatically. But if you use AWS CloudFormation or the CLI, you must create the role manually with the correct trust policy and permissions. The role needs permission to publish to CloudWatch Logs or S3. If the role is missing, the flow log will be created but will never publish data.

Finally, you should know how to aggregate flow logs across multiple accounts. Using AWS Organizations, you can create a central logging account and deliver flow logs from all member accounts to that account's S3 bucket. This is essential for security teams that need a single pane of glass. The member accounts must have a bucket policy that grants the central account permission to write objects.

## Memory tip

Flow Logs Flow From Hypervisor: For every packet, the hypervisor logs the source, destination, action, and port tuple in a single record. Think FLOW = Five-tuple Log of Wires.

## FAQ

**Does enabling VPC Flow Logs affect the performance of my EC2 instances?**

No, VPC Flow Logs are captured by the hypervisor, not by the instance itself. There is no performance impact on the virtual machine. The logs are generated and published without consuming resources from your instances.

**Can I use VPC Flow Logs to capture traffic between two instances in the same subnet?**

Yes, you can. Create a flow log at the VPC or subnet level, or on both network interfaces. The logs will capture the traffic as long as the instances communicate directly without going through a load balancer or NAT device.

**How long does it take for flow log data to appear after I enable it?**

With the default 10-minute aggregation interval, data appears in the destination (CloudWatch Logs or S3) within approximately 15 minutes. With a 1-minute interval, data appears sooner, usually within 2 minutes.

**What is the difference between logging ALL traffic and logging only REJECT traffic?**

Logging ALL records both accepted and rejected traffic. Logging only REJECT will capture only denied traffic, which reduces log volume significantly. It is useful for security monitoring where you only care about blocked connection attempts.

**Can I delete a flow log after creating it?**

Yes, you can delete a flow log at any time. Deleting the flow log stops capturing new traffic but does not delete previously published logs from CloudWatch Logs or S3. You must manage the old logs separately if you want to remove them.

**Do VPC Flow Logs capture IPv6 traffic?**

Yes, VPC Flow Logs support IPv6 traffic. The source and destination addresses in the log will be IPv6 addresses if the traffic uses IPv6. You must have an IPv6 CIDR block attached to your VPC and subnet.

**Can I use VPC Flow Logs to monitor traffic that goes through a VPC peering connection?**

Yes, as long as you enable flow logs on the network interfaces in each VPC. Traffic that traverses the peering connection will be captured in the logs of the VPC where the interface resides. However, you cannot centrally monitor a peering connection in a single flow log if the VPCs are in different accounts.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/vpc-flow-logs