Think All Clouds Are Equally Risky? These Numbers Say Otherwise
New Honeypot study finds hackers don’t treat AWS, Azure, and Google the same
Cyber security attack myths say attackers are equal-opportunity opportunists, pouncing on whatever system shows a vulnerable port. James Smith’s December 2024 SANS paper "The Flavor of Clouds: Are Some Cloud Platforms More Attractive to Attackers?" pushes back at that notion and widens the conversation about cloud computing security.
Over 15 days, Smith ran identical low-interaction honeypots in Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). Each instance exposed an SSH daemon and two tiny Apache sites, plus a deliberately broken link meant to lure human intruders. By the end of the test, the three servers had logged 106,000 events and starkly different levels of attention. This underscored how cloud network security exposures vary by provider.
Dissecting the hit parade
Raw traffic told the first story. The AWS box recorded 21,377 malicious requests, barely half the 40,073 seen on GCP and less than half the 44,473 that pounded Azure. The gap widened on the SSH front: Azure absorbed 37,096 brute-force attempts, GCP 32,438, but AWS only 9,452. A Chi-square goodness-of-fit test put the odds of this spread being random at essentially zero, hinting at either attacker indifference toward Amazon hosts or hidden mitigation on Amazon’s side.
The count of unique bots revealed more. Only 302 distinct IP addresses tried AWS over SSH, compared with 914 for Azure and 736 for GCP. Strikingly, fewer than one percent of IPs overlapped across all three clouds, suggesting bot herders direct specific nodes at specific providers rather than spraying the entire address space.
Is AWS better shielding or simply less attractive?
Why did the Amazon honeypot draw so little fire? Smith stops short of pinning the cause on any single factor. One suspicion is AWS Shield Standard, one of the built-in cloud security services Amazon enables by default. Shield is documented for web traffic, but it could be throttling noisy scanners on other ports as collateral damage. Another possibility is attacker economics. If old username lists work just fine against Azure and GCP, botmasters may see no need to burn compute cycles on AWS. Supporting that view, Smith found the credential dictionaries aimed at Amazon were dramatically shorter. They contained 245 unique usernames versus more than 1,300 for each rival cloud.
Bots know their neighborhoods
The study also undercuts the stereotype of bots as mindless crawlers. For port 80 traffic, each cloud attracted roughly the same number of distinct attacking systems even though AWS logged far more individual HTTP requests. On port 443 the picture flipped. The three providers saw nearly identical bot infrastructure, yet Amazon received the fewest interaction counts. This pattern is again consistent with rate-limiting on the provider side rather than attacker preference.
Discovery times painted a similar portrait of tailored targeting. Azure’s SSH service was found in just over 15 minutes. GCP’s was found in under half an hour, and AWS’s in roughly an hour. Faster discovery correlated almost perfectly with the size of the attacking bot herd. This reinforces the idea that reconnaissance resources are metered out strategically.
Practical lessons for cloud architects
Smith’s experiment delivers an uncomfortable truth: “fewer attacks” does not equal “lower risk.” A single bot with a concise username list can compromise a weakly configured SSH server as quickly as a swarm of scanners. Enterprises therefore should enable key-based logins and restrict port 22 at the firewall before any instance meets the open Internet. Similarly, web prototypes deserve full TLS, patching, and logging from day one. The honeypots’ port 80 endpoints were discovered in as little as five minutes. All of these basics form the bedrock of sound cloud data security.
Centralized visibility remains critical. Because bot IP overlap is so low, organizations that aggregate logs across multiple clouds will spot coordinated campaigns others might miss. Provider-native defenses - AWS Shield, Azure DDoS Protection, Google Cloud Armor - should be treated as baselines, not silver bullets. Finally, the utter absence of hands-on-keyboard activity in the study suggests that while bots dominate the noise floor, defenders cannot relax. Real humans often arrive later, armed with the data those bots collect.
Beyond the numbers
Smith’s test bed was intentionally compact: one server per cloud for a little over two weeks. Scaling the setup to dozens of instances, extending the timeline, and including an on-premises control group would further clarify whether Amazon’s apparent safety margin is structural or situational.
Still, the findings already challenge a popular assumption. Attackers do play favorites, and cloud choice can influence how much automated pressure your perimeter faces. For security teams, that nuance is both a warning and an opportunity to fine-tune defenses before the next wave of bots comes knocking.
To explore more WhatIsMyIP tech news, check out these articles on the basic security steps every student forgets and improvements to zero-trust with a new VPN detection.
