Back to BlogAlert on 10+ Rejected SSH Attempts With VPC Flow Logs Monitoring

Alert on 10+ Rejected SSH Attempts With VPC Flow Logs Monitoring

NTNetverge TeamNetverge editorial teamUpdated
vpc flow logs monitoringAWS flow logsaws vpc flow logs analysiscloud network monitoringVPC traffic analysis

VPC Flow Logs capture IP-level traffic metadata and should be monitored through real-time CloudWatch metric filters, with a parallel copy archived to S3 for historical analysis. That pairing covers both immediate detection and long-term investigation. The main tradeoffs to plan around are aggregation interval, delivery latency, and the storage and query costs that come with high-volume traffic.

TL;DR:

  • VPC Flow Logs should be monitored in real-time via CloudWatch metric filters and archived to S3 for historical analysis, balancing latency and cost considerations.
  • They record detailed IP-level traffic metadata, including IP addresses, ports, protocol, action, and timestamps, and can be published to CloudWatch, S3, or Firehose destinations depending on monitoring needs.
  • Creating and configuring flow logs requires proper IAM permissions, a fixed setup that cannot be modified post-creation, and separate subscriptions for different destinations for best practices.
  • CloudWatch Logs Insights and Athena enable investigation and alerting on rejected traffic, top talkers, and spikes, but near-instant alerts are limited by inherent delivery latency of around 5 to 10 minutes.
  • Pairing flow logs with additional telemetry tools, like network firewalls or device telemetry, is essential for root cause analysis, while centralizing logs in a shared account helps manage costs and access.

Table of Contents

What VPC Flow Logs record and where they can go

Each flow log record captures a 5-tuple (source and destination IP, source and destination port, protocol), packet and byte counts, start and end timestamps, an accept or reject action, and a log-status field. Fields like pkt-srcaddr and pkt-dstaddr help you see the actual packet addresses when network address translation is in play, according to the flow log records guide.

You publish flow logs to one of three destinations, each suited to a different job, per the VPC Flow Logs guide:

  • CloudWatch Logs: best for real-time monitoring, metric filters, and alarms.
  • Amazon S3: best for archival, compliance retention, and Athena-based historical queries.
  • Amazon Data Firehose: best for streaming records to a SIEM or other third-party analytics tool.

Flow logs are strong for security investigations, connectivity troubleshooting, and validating security group behavior. They will not tell you what happened at the application layer, so pair them with other telemetry when you need that depth.

How to create and configure VPC Flow Logs

Flow logs attach at three possible scopes, and the scope you pick determines what you see:

  1. Network interface (ENI): narrowest scope, useful for isolating a single instance's traffic.
  2. Subnet: captures every ENI in that subnet, useful for tier-level visibility.
  3. VPC: broadest scope, captures every ENI across the VPC.
  4. Choose a traffic type: ACCEPT, REJECT, or ALL, depending on whether you care about blocked attempts, successful flows, or both.
  5. Set the aggregation interval: the default is 10 minutes, with an optional 1-minute interval for higher-resolution capture, as noted in the flow log records guide.
  6. Pick a destination and attach the matching permission: a CloudWatch log group with a resource policy, an S3 bucket ARN with a bucket policy, or a Firehose delivery stream with an IAM role, following the steps in the S3 delivery guide.

Missing IAM permissions or an incomplete resource policy are the most common reasons flow logs fail to deliver. Once a flow log is created, its configuration is fixed: changing the interval, fields, or destination means deleting and recreating the subscription.

Pro Tip: Create separate flow log subscriptions for CloudWatch and S3 rather than trying to repurpose one, since each destination has its own policy requirements and you cannot edit an existing subscription to add a second target.

Monitoring, querying, and alerting with Insights, filters, and Athena

CloudWatch Logs Insights handles interactive investigation well. Common query patterns include ranking top talkers by byte count, isolating rejected traffic on port 22, and spotting sudden spikes on a specific destination port. From there, metric filters convert those patterns into standing alarms.

  • Build a metric filter that matches REJECT entries on port 22, then attach an alarm.
  • Set threshold alarms for spikes in rejected traffic or unusual outbound byte volume.
  • Archive the same logs to S3 and query them with Athena for scheduled historical reports.
  • Forward records through Firehose to a SIEM when you need cross-source correlation.

A working example: AWS documents an alarm pattern that fires when there are 10 or more rejected TCP connection attempts on port 22 within one hour, a practical baseline for catching brute-force SSH probing early.

Athena queries against S3-archived logs support the same investigative questions at scale, using prebuilt table templates described in the Athena querying guide.

Analyzing flow logs for security investigations and troubleshooting

A structured investigation beats an open-ended log search every time.

  1. Filter by ENI or instance ID first, then narrow by direction, port, and action.
  2. Run a top-talkers query to rank sources or destinations by byte volume.
  3. Remember that source IPs on ephemeral ports often belong to short-lived connections, not the instance itself, so cross-check against instance IDs before drawing conclusions.
  4. Correlate suspicious flows with GuardDuty and Amazon Detective findings, then check the relevant security group and network ACL rules to confirm whether the traffic should have been blocked.
  5. Look for reject spikes on unusual ports, unexpected outbound connections to unfamiliar IP ranges, and mismatches between expected security group rules and observed traffic.

These checks turn a raw log dump into a short list of flows worth escalating.

Best practices for centralization, retention, and cost control

Centralizing flow logs into a dedicated Log Archive account is the pattern AWS itself recommends, since it prevents tampering and gives every account and region a single analytics integration point, per AWS prescriptive guidance.

  • Tag CloudWatch log groups and S3 buckets by team or workload so costs can be allocated accurately.
  • Set S3 lifecycle rules to transition older logs to cheaper storage classes, and set CloudWatch retention periods instead of leaving them indefinite.
  • Partition Athena queries by date and account to keep scan costs down as archives grow.
  • Apply strict, narrowly scoped resource policies on every S3 bucket and log group destination so only the flow log service can write to it.

Cost comes from ingestion, storage, and query charges together, and tuning aggregation interval and retention is the main lever for controlling it, according to the VPC Flow Logs guide.

Pro Tip: Route every account's flow logs to the same centralized S3 bucket and log group set rather than letting each team stand up its own, so retention and access policy only have to be managed once.

Multiple accounts routing logs to central storage

Limitations and a troubleshooting checklist

Flow logs record IP and transport-layer metadata only. They cannot see DNS hostnames or application-layer content, so pair them with AWS Network Firewall or Route 53 Resolver DNS Firewall when you need that level of detail, per AWS re:Post guidance. Some records can also be skipped under high load, and configuration is immutable once a flow log is created, per the limitations guide.

  • Expect delivery latency of about 5 minutes to CloudWatch Logs and about 10 minutes to S3, so treat near-instant alerting as unrealistic.
  • Check the log-status field first when records seem to be missing.
  • Confirm ENI, subnet, or VPC scope matches what you intended to capture.
  • Watch CloudWatch query limits and network ACL rule counts, since both can cap how far automated remediation scripts can scale.

Netverge perspective: pairing flow logs with full-stack observability

VPC Flow Logs are a strong signal on their own, but they describe traffic, not root cause. Correlating a reject spike with a device-level event, a routing change, or a hardware fault usually requires stitching together several tools by hand.

Netverge consolidates that correlation work. Pairing cloud flow data with Vergepoints hardware telemetry and other network signals gives one context layer instead of several disconnected dashboards, and AI-driven triage narrows a spike in rejected traffic to a probable cause faster than a manual Insights query alone. For MSPs and multi-site teams already leaning on CloudWatch and Athena, that consolidation is the next practical step once the basics are in place.

— Jim

Try Netverge for consolidated flow log visibility

Watching CloudWatch metric filters and running Athena queries against S3 archives works, but it takes a team's time to maintain both pipelines and correlate the results by hand. Netverge brings that traffic data into one dashboard alongside device telemetry and AI-driven triage, cutting the manual correlation step that usually slows down incident response.

Netverge

Teams evaluating a unified path can start with the Starter Package at $299 per month, or review Hardware Vergepoints for on-site visibility at $49 per month per device.

Authoritative documentation and guides

For exact configuration steps, field definitions, and current service limits, go directly to the source. These are the primary references this guide draws from, useful when you need to verify a setting before deploying to production:

FAQ

How can I check VPC Flow Logs?

You can check flow logs directly in CloudWatch Logs Insights for real-time searches, or query archived copies in S3 using Amazon Athena for historical analysis. Both methods rely on the destination you configured when creating the flow log subscription.

What are VPC Flow Logs and how do they work?

VPC Flow Logs capture IP-level metadata for traffic going to and from network interfaces, including source and destination addresses, ports, protocol, and whether the traffic was accepted or rejected. Records are published to CloudWatch Logs, S3, or Data Firehose, depending on the destination you choose.

What are the limitations of VPC flow logs?

Flow logs capture transport and network-layer metadata only, so they cannot show DNS hostnames or application-layer content, per AWS guidance. Configuration is also immutable once created, and some records can be skipped under heavy load.

How expensive are VPC flow logs?

Cost depends on ingestion volume plus the storage and query charges tied to your chosen destination, whether that is CloudWatch vended logs, S3 storage, or Athena scans, according to the VPC Flow Logs guide. Tagging destinations and setting retention and lifecycle policies are the main ways to keep that cost predictable.

Recommended