GuardDuty Lambda Protection for Serverless MCP Servers — Runtime Threat Monitoring

Enable Lambda protection

Lambda protection is a GuardDuty feature that must be explicitly enabled — it is not included in the base detector. Enabling applies to all Lambda functions in the account in the enabled region; there is no per-function selective coverage as of 2026.

# Enable Lambda network activity monitoring
aws guardduty update-detector \
  --detector-id abc1234567890abcdef1234567890 \
  --features '[
    {
      "Name": "LAMBDA_NETWORK_LOGS",
      "Status": "ENABLED"
    }
  ]'

# Verify Lambda protection status
aws guardduty get-detector \
  --detector-id abc1234567890abcdef1234567890 \
  --query 'Features[?Name==`LAMBDA_NETWORK_LOGS`]'
# Expected: [{"Name": "LAMBDA_NETWORK_LOGS", "Status": "ENABLED", ...}]

# For Organizations: enable Lambda protection on all member accounts
# (run in delegated admin account)
aws guardduty update-organization-configuration \
  --detector-id  \
  --features '[
    {
      "Name": "LAMBDA_NETWORK_LOGS",
      "AutoEnable": "ALL"
    }
  ]'

Lambda protection pricing: first 1 million Lambda invocations per month per account are free. Above that, the cost is $0.20 per 1 million invocations. For an MCP server handling 100 requests/day (3,000/month), this is well within the free tier. For high-traffic MCP deployments (1M+ invocations/month), factor the cost into your security budget — it is typically less than 1% of Lambda compute cost for most workloads.

Lambda-specific finding types

GuardDuty generates Lambda-specific findings in the Lambda resource type category. The finding's resource.lambdaDetails field identifies the function; service.action.networkConnectionAction describes the suspicious connection.

# Get Lambda finding details — identify which function and what connection
aws guardduty get-findings \
  --detector-id abc1234567890abcdef1234567890 \
  --finding-ids "lambda-finding-id" \
  --query 'Findings[0].{
    Type:Type,
    Severity:Severity,
    Function:Resource.LambdaDetails,
    Connection:Service.Action.NetworkConnectionAction
  }'

# LambdaDetails structure:
# {
#   "FunctionName": "mcp-tool-handler",
#   "FunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:mcp-tool-handler",
#   "FunctionVersion": "$LATEST",
#   "Role": "arn:aws:iam::123456789012:role/mcp-tool-handler-role",
#   "Tags": [{"Key": "Service", "Value": "mcp-api"}],
#   "VpcConfig": {
#     "SubnetIds": ["subnet-abc123"],
#     "SecurityGroupIds": ["sg-def456"],
#     "VpcId": "vpc-ghi789"
#   }
# }

# NetworkConnectionAction structure:
# {
#   "ConnectionDirection": "OUTBOUND",
#   "Protocol": "UDP",
#   "LocalPortDetails": {"Port": 53, "PortName": "DNS"},
#   "RemoteIpDetails": {
#     "IpAddressV4": "198.51.100.10",
#     "Country": {"CountryName": "Netherlands"},
#     "Organization": {"Asn": "12345", "AsnOrg": "Mining Pool ASN"}
#   },
#   "RemotePortDetails": {"Port": 53, "PortName": "DNS"}
# }

False positives in Lambda-based MCP servers

Lambda MCP servers making outbound API calls to LLM providers and external services will generate initial Execution:Lambda/SuspiciousNetworkActivity.B findings because GuardDuty uses a baseline period to learn normal behavior — connections to IP ranges not seen in the first 2 weeks of monitoring are flagged as "first-seen destinations." Create suppression filters for known-good destinations immediately after enabling Lambda protection to prevent noise from blocking real alerts.

# Suppress SuspiciousNetworkActivity for known Anthropic API IP range
# (Note: Anthropic uses CloudFront, so destination IPs vary — suppress by ASN or country is less reliable)
# Best approach: suppress by finding type + function name for AI provider calls

aws guardduty create-filter \
  --detector-id abc1234567890abcdef1234567890 \
  --name "mcp-llm-api-outbound-suppression" \
  --action ARCHIVE \
  --rank 1 \
  --finding-criteria '{
    "Criterion": {
      "type": {
        "Equals": ["Execution:Lambda/SuspiciousNetworkActivity.B"]
      },
      "resource.lambdaDetails.functionName": {
        "Prefix": ["mcp-"]
      }
    }
  }'

# More targeted: suppress only connections to specific ASN ranges
# Cloudflare (AS13335) hosts api.anthropic.com via Cloudflare; AWS AS16509 for Bedrock
aws guardduty create-filter \
  --detector-id abc1234567890abcdef1234567890 \
  --name "mcp-ai-provider-asn-suppression" \
  --action ARCHIVE \
  --rank 2 \
  --finding-criteria '{
    "Criterion": {
      "type": {
        "Equals": ["Execution:Lambda/SuspiciousNetworkActivity.B"]
      },
      "service.action.networkConnectionAction.remoteIpDetails.organization.asn": {
        "Equals": ["13335", "16509", "14618"]
      }
    }
  }'

# After the baseline period (2-3 weeks), SuspiciousNetworkActivity.B findings
# naturally decrease as GuardDuty learns your Lambda's normal outbound patterns.
# Keep targeted suppression for CryptoCurrency:Lambda/* and Backdoor:Lambda/* active —
# these are threat-intelligence-based (not behavioral) and have very low false-positive rates.

Do not suppress CryptoCurrency:Lambda/BitcoinTool or Backdoor:Lambda/C&CActivity.B — these are based on known threat intelligence (specific IP/domain threat feeds) with very low false-positive rates. If you see these findings for your production MCP function, treat them as confirmed security events, not noise.

Lambda protection vs. Lambda Insights and X-Ray

Lambda protection, Lambda Insights, and X-Ray serve different monitoring purposes for Lambda-based MCP servers. All three can run simultaneously without conflict.

GuardDuty Lambda protection operates below the function level — at the Lambda service network layer — and does not increase Lambda function cold start time, execution duration, or memory usage. It has zero performance impact on your MCP server's response latency.

Failure modes reference