Back to Blog
Cloud Security5 min read

Detecting Cloud Threats Without a SOC

You can't afford a 24/7 security team, but you can get real threat detection. Here's how to use cloud-native tools to punch above your weight.

Every cloud security article eventually recommends "implement a SIEM" and "hire a SOC team." For a 50-person company spending carefully on infrastructure, that advice is useless.

Here's what's actually useful: the cloud providers have built remarkably good detection capabilities into their platforms. You can get real threat detection—not just compliance checkboxes—for a fraction of the cost of building a security operations center.

What Cloud Providers Give You

Each major cloud provider has mature threat detection services:

AWS GuardDuty — Analyzes CloudTrail logs, VPC Flow Logs, and DNS logs to detect suspicious activity. It finds things like:

  • API calls from malicious IPs
  • Unusual instance or data access patterns
  • Compromised credentials (using patterns like impossible travel)
  • Cryptocurrency mining
  • Data exfiltration indicators

Azure Defender for Cloud (now Microsoft Defender for Cloud) — Similar concept for Azure resources. It detects:

  • Suspicious Azure AD activity
  • Unusual resource creation or access
  • Known malware and attack patterns
  • Misconfigurations that indicate compromise

Google Security Command Center — Google's equivalent. Detects:

  • Unusual API usage
  • Service account abuse
  • Cryptomining
  • Data exfiltration

These services are managed—you don't operate them, you consume their findings. Turn them on, configure alerting, and you have continuous threat monitoring.

The Cost Reality

GuardDuty typically costs $1-5 per account per month for small environments, scaling based on log volume. Azure Defender has a free tier for many capabilities. Google SCC has free and premium tiers.

Compare that to a SOC analyst salary ($80-120K+) or a managed SOC service ($5-20K/month), and the value proposition is clear.

Setting This Up Right

Turning on the service is step one. Making it useful requires more work.

1. Enable the Services

For AWS:

aws guardduty create-detector --enable

For Azure:

  • Azure Portal → Microsoft Defender for Cloud → Enable

For GCP:

  • Security Command Center → Enable organization-level

Enable in all accounts and regions. Attackers find the unmonitored corners.

2. Configure Alerting

These services generate findings. You need those findings to reach humans who can act on them.

For AWS:

  • EventBridge rule on GuardDuty findings
  • Route high-severity to SNS → email, Slack, or PagerDuty
  • Consider a Lambda function to filter noise

For Azure:

  • Defender for Cloud alert routing to email/Slack
  • Logic Apps for automated response workflows

For GCP:

  • SCC findings export to Pub/Sub
  • Cloud Functions for routing and response

At minimum, high and critical severity findings should reach someone within minutes.

3. Build Response Playbooks

When an alert fires, what do you do? Document it:

Compromised Credentials Alert (AWS):

  1. Rotate the affected access keys immediately
  2. Review CloudTrail for actions taken with those credentials
  3. Check for persistence mechanisms (new users, new keys, new roles)
  4. If significant damage, initiate full incident response

Unusual Data Access (Azure):

  1. Determine what data was accessed and by whom
  2. Verify whether access was legitimate
  3. If unauthorized, revoke access and reset credentials
  4. Review for data exfiltration

You don't need a 50-page runbook. A one-page guide for your top 5 alert types covers most situations.

4. Tune for Your Environment

Out of the box, you'll get some false positives. Common sources:

  • Vulnerability scanners and security tools you own
  • Legitimate automation from unusual sources
  • Third-party integrations with odd access patterns

Suppress known-good patterns so real threats don't get lost in noise.

What This Won't Do

Cloud-native detection has limits:

Application-layer attacks — GuardDuty doesn't understand your application. SQL injection, business logic attacks, and abuse of legitimate features require application-level monitoring.

Insider threats with legitimate access — If someone uses their real credentials to do things they're authorized to do, detection is harder. UEBA (User and Entity Behavior Analytics) helps here but adds complexity.

Sophisticated attackers — Nation-state actors and advanced persistent threats use techniques designed to evade detection. Cloud-native tools catch common attacks, not exotic ones.

Cross-cloud visibility — If you're multi-cloud, you need correlation across providers. That's where SIEM tools add value—when you've outgrown single-cloud detection.

When to Graduate to More

You've outgrown basic cloud-native detection when:

  • You're multi-cloud and need unified visibility
  • You're collecting application logs that need correlation
  • You're in an industry with specific detection requirements (financial, healthcare)
  • You've had incidents that cloud-native tools missed

At that point, consider:

  • Managed SIEM services — Less staffing than running your own
  • MDR (Managed Detection and Response) — Outsourced SOC with your tools
  • Cloud-native SIEM — AWS Security Lake, Azure Sentinel, Chronicle—easier to integrate than traditional SIEMs

But start with what the cloud gives you. Most small companies never need more.


Need help configuring cloud security monitoring or building response playbooks? Our cloud security services help organizations implement effective detection without enterprise complexity. Let's talk.

Jonathan Carpenter
Jonathan Carpenter
Founder, Anchor Cyber Security
Share:

Want to discuss this topic?

Let's talk about how these insights apply to your organization.

Get in Touch