Synqly Adds AWS Network Security Integration for DNS and Traffic Data

Traffic logs answer where data moved. DNS logs answer what a system was trying to reach before it moved anywhere, and a security product that only has one of those two signals is working with half the picture on a compromised host. The new AWS network security integration is one of the few in Synqly’s Network Security category that covers both.

AWS Network Security connects to two separate logging sources inside Amazon’s cloud platform: VPC Flow Logs, which capture accepted and rejected traffic at the network interface level, and Route 53 Resolver query logs, which record the DNS queries resources inside a VPC actually made. Most cloud network security integrations, including Synqly’s own Azure and Google Cloud connectors, expose traffic data alone. Because AWS also exposes resolver level DNS logging as a first class capability, the AWS network security integration gets four operations instead of two.

Through the AWS network security integration, an OEM product can query traffic events and traffic log configurations, the same pair of capabilities available for Azure and Google Cloud, normalized to the OCSF Network Activity class. It can also query DNS events, normalized separately to the OCSF DNS Activity class, and query DNS log configurations to discover what resolver logging is already active in a customer’s account before requesting data from it. That DNS layer is what lets a product catch a command and control beacon or a DNS tunneling attempt at the moment a compromised instance starts resolving a suspicious domain, rather than waiting for that instance to actually establish an outbound connection that shows up in a traffic log. Full setup instructions, including how to configure both Flow Logs and Resolver query logging for Synqly to read, are in the AWS Network Security Configuration Guide on the Synqly documentation site.

A concrete detection benefits directly from having both signals available in one place. Consider a compromised EC2 instance that begins resolving a sequence of algorithmically generated domain names, a common pattern for malware calling home to infrastructure that rotates faster than static IP based blocklists can keep up with. Query DNS events on the AWS network security integration surfaces that unusual resolution pattern the moment it starts, well before the instance necessarily completes an outbound connection worth flagging in a traffic log. A detection product watching both signals can correlate the DNS anomaly with whatever traffic follows it, building a stronger case for a real compromise than either signal would support on its own.

AWS has one of the broadest footprints of any partner in the Synqly ecosystem, and network security is a late addition to that footprint rather than an early one. Synqly customers already connect to AWS through Amazon Inspector in Vulnerabilities, through AWS Cloud Security, and through AWS IAM Identity. This new AWS network security integration adds to that already substantial list rather than opening AWS coverage for the first time, and each of those other pages documents its own use cases without repetition here.

The DNS and traffic combination matters most for detection engineering teams building lateral movement and exfiltration detections specifically for AWS workloads, since the two signals catch different stages of the same attack. A traffic log shows that a workload talked to an unexpected external IP. A DNS log can show that same workload resolving a domain associated with known malicious infrastructure before that connection ever happened, which gives a detection engine an earlier and often more reliable signal to act on. Building both of those pipelines independently, on top of Flow Logs and Resolver logs that have their own separate configuration and delivery mechanisms inside AWS, is meaningfully more work than building either one alone.

This AWS network security integration is part of Synqly’s Network Security Unified API, and it now sits alongside Azure and Google Cloud coverage with a genuinely different, and in this case broader, capability set. For an OEM product supporting customers across all three major clouds, Synqly’s job is making that difference in underlying provider capability invisible to a product’s own detection logic, wherever a customer happens to be running.