AWS Security Hub can now discover and assess Microsoft Azure virtual machines, container images, Function Apps, and identities, giving multicloud security teams a shared queue for Azure and AWS risks. The July 14 expansion arrives alongside GuardDuty AI Protection, automated AI-powered investigations, and a new inventory for tracking models, agents, endpoints, and their supporting infrastructure.
AWS detailed the releases in its Security Blog, while SiliconANGLE reported that the company is positioning Security Hub as a broader security control plane rather than an AWS-only findings dashboard. For Windows and Azure administrators, the immediate payoff is native Azure posture and vulnerability data inside an AWS security workflow—without first routing every signal through a separate third-party platform.
The capabilities are not all at the same stage. Azure monitoring, GuardDuty AI Protection, and Security Hub AI inventory are generally available, while GuardDuty AI-powered investigations remain in preview across 10 AWS Regions.
Security Hub can discover Azure Virtual Machines, container images, Function Apps, and identities, then evaluate them for software vulnerabilities, internet exposure, and configuration problems. Its posture checks align with the CIS Microsoft Azure Foundations Benchmark, giving administrators a recognizable baseline for assessing Azure subscriptions.
AWS says Azure findings use the same format, prioritization system, automation, and response workflows as findings from AWS resources. That consistency matters for security operations centers responsible for both Azure-hosted Windows Server systems and AWS workloads: analysts can triage risks from one queue instead of reconciling different severity models and alert schemas before beginning an investigation.
The launch does not make Security Hub a replacement for Microsoft Defender for Cloud, Microsoft Sentinel, or Azure Policy. Those Microsoft products remain more deeply connected to Azure configuration, identity, endpoint, and security operations. AWS is instead targeting organizations whose operational center of gravity already sits in Security Hub but whose infrastructure has expanded into Azure.
That distinction should shape deployment decisions. A company running most of its workloads in Azure is unlikely to move its entire security operation merely because Security Hub can now ingest and evaluate several Azure resource types. An AWS-heavy enterprise with a meaningful collection of Azure subscriptions, however, may find the unified prioritization useful—particularly if its security staff already maintains Security Hub automations and response playbooks.
Azure resources are charged at the same rates as equivalent AWS resources, according to AWS, with no separate multicloud surcharge. The company is also offering an independent 30-day trial, allowing customers to test Azure coverage without consuming the trial associated with another Security Hub feature.
The initial resource list is important because it also defines the boundaries of the release. Azure Virtual Machines, Function Apps, identities, and container images cover several high-value attack surfaces, but they do not represent every Azure service an enterprise might need to monitor. AWS says support for additional clouds will follow, but it has not provided a detailed public timetable in the announcement.
One threat AWS is emphasizing is cost harvesting: an attacker steals credentials and uses the victim’s access to run costly foundation-model inference. Unlike conventional cryptojacking, the attacker does not need to deploy cryptocurrency-mining infrastructure. Access to an existing AI service can be monetized—or simply abused to inflict a large cloud bill—through repeated model calls.
AWS says GuardDuty AI Protection detects anomalous invocations and can identify prompt-injection attempts through its integration with Amazon Bedrock Guardrails. The service is generally available to GuardDuty customers with a 30-day free trial.
For administrators, the billing angle is not incidental. Rapid increases in inference spending may be one of the first externally visible signs that a service account, access key, or application identity has been compromised. Cloud cost alerts should therefore feed incident-response processes rather than remain confined to finance or FinOps teams.
The practical response remains conventional even when the abused resource is an AI model: revoke exposed credentials, examine CloudTrail activity, identify the calling workload, review IAM permissions, and determine whether the attacker reached associated data stores or services. GuardDuty can surface the anomalous activity, but it cannot eliminate the need for credential hygiene and tightly scoped access policies.
Each investigation produces a disposition assessment, confidence score, supporting evidence, MITRE ATT&CK classification, and recommended action. Those recommendations can include suppressing an alert, containing an affected resource, or beginning remediation.
The potential benefit is reduced triage time, especially in large AWS Organizations where one suspicious event may touch several accounts and services. The risk is that administrators begin treating an AI-generated disposition as a final verdict rather than an aid to investigation.
Confidence scoring is not proof. Security teams evaluating the preview should compare its conclusions against analyst decisions, track false-positive and false-negative rates, and require human review before destructive containment actions are automated. The feature’s value will depend less on how polished its summaries appear and more on whether its evidence reliably leads responders back to the relevant CloudTrail events, identities, and resources.
For AWS-managed services, the inventory uses AWS Config resources to catalog workloads across Amazon Bedrock, SageMaker, and AgentCore. Runtime analysis can also find models hosted on EC2, ECS, and EKS, as well as external model endpoints contacted by AWS workloads.
Security Hub then maps those assets to supporting compute, networking, IAM roles, and data stores. It also correlates the inventory with signals such as GuardDuty findings, allowing an anomalous model invocation to be viewed alongside the infrastructure and identities connected to it.
This could expose the AI equivalent of shadow IT: an experimental SageMaker endpoint left running, a Bedrock agent created for a proof of concept, or a Lambda function quietly calling an external model API. In a large organization, these deployments can spread across hundreds of accounts before the central security team establishes governance.
The inventory is included in the Security Hub Essentials plan at no additional cost, according to AWS. That removes one barrier to adoption, although customers still need suitable AWS Config coverage and runtime visibility if they expect the catalog to be complete.
Partner findings are emitted using the Open Cybersecurity Schema Framework, or OCSF, and aggregated in Security Hub. AWS says it is working toward correlating signals from different products into a single exposure or attack path rather than presenting endpoint, identity, and cloud alerts as unrelated incidents.
That is the most ambitious part of the announcement—and the least complete. The Azure assessments and AI inventory are usable capabilities now, but broad cross-vendor correlation depends on the depth, consistency, and timeliness of each integration. Normalizing alerts into OCSF is a useful foundation; producing trustworthy attack-path analysis from them is a considerably harder engineering and operational problem.
For mixed Microsoft and AWS estates, the July 14 release creates a practical new option: Azure risks can now enter existing Security Hub workflows, while AWS-native AI workloads gain dedicated inventory and threat detection. The next test is whether AWS can expand Azure resource coverage and turn its growing collection of standardized findings into fewer, better incidents rather than one more centralized pile of alerts.
AWS detailed the releases in its Security Blog, while SiliconANGLE reported that the company is positioning Security Hub as a broader security control plane rather than an AWS-only findings dashboard. For Windows and Azure administrators, the immediate payoff is native Azure posture and vulnerability data inside an AWS security workflow—without first routing every signal through a separate third-party platform.
The capabilities are not all at the same stage. Azure monitoring, GuardDuty AI Protection, and Security Hub AI inventory are generally available, while GuardDuty AI-powered investigations remain in preview across 10 AWS Regions.
Azure Findings Move Into the AWS Risk Queue
Security Hub can discover Azure Virtual Machines, container images, Function Apps, and identities, then evaluate them for software vulnerabilities, internet exposure, and configuration problems. Its posture checks align with the CIS Microsoft Azure Foundations Benchmark, giving administrators a recognizable baseline for assessing Azure subscriptions.AWS says Azure findings use the same format, prioritization system, automation, and response workflows as findings from AWS resources. That consistency matters for security operations centers responsible for both Azure-hosted Windows Server systems and AWS workloads: analysts can triage risks from one queue instead of reconciling different severity models and alert schemas before beginning an investigation.
The launch does not make Security Hub a replacement for Microsoft Defender for Cloud, Microsoft Sentinel, or Azure Policy. Those Microsoft products remain more deeply connected to Azure configuration, identity, endpoint, and security operations. AWS is instead targeting organizations whose operational center of gravity already sits in Security Hub but whose infrastructure has expanded into Azure.
That distinction should shape deployment decisions. A company running most of its workloads in Azure is unlikely to move its entire security operation merely because Security Hub can now ingest and evaluate several Azure resource types. An AWS-heavy enterprise with a meaningful collection of Azure subscriptions, however, may find the unified prioritization useful—particularly if its security staff already maintains Security Hub automations and response playbooks.
Azure resources are charged at the same rates as equivalent AWS resources, according to AWS, with no separate multicloud surcharge. The company is also offering an independent 30-day trial, allowing customers to test Azure coverage without consuming the trial associated with another Security Hub feature.
The initial resource list is important because it also defines the boundaries of the release. Azure Virtual Machines, Function Apps, identities, and container images cover several high-value attack surfaces, but they do not represent every Azure service an enterprise might need to monitor. AWS says support for additional clouds will follow, but it has not provided a detailed public timetable in the announcement.
GuardDuty Watches for Stolen AI Compute
GuardDuty AI Protection extends AWS threat detection to Amazon Bedrock and Amazon SageMaker. It analyzes AWS CloudTrail data events to establish normal model-invocation behavior and identify deviations that may indicate compromised credentials or unauthorized use.One threat AWS is emphasizing is cost harvesting: an attacker steals credentials and uses the victim’s access to run costly foundation-model inference. Unlike conventional cryptojacking, the attacker does not need to deploy cryptocurrency-mining infrastructure. Access to an existing AI service can be monetized—or simply abused to inflict a large cloud bill—through repeated model calls.
AWS says GuardDuty AI Protection detects anomalous invocations and can identify prompt-injection attempts through its integration with Amazon Bedrock Guardrails. The service is generally available to GuardDuty customers with a 30-day free trial.
For administrators, the billing angle is not incidental. Rapid increases in inference spending may be one of the first externally visible signs that a service account, access key, or application identity has been compromised. Cloud cost alerts should therefore feed incident-response processes rather than remain confined to finance or FinOps teams.
The practical response remains conventional even when the abused resource is an AI model: revoke exposed credentials, examine CloudTrail activity, identify the calling workload, review IAM permissions, and determine whether the attacker reached associated data stores or services. GuardDuty can surface the anomalous activity, but it cannot eliminate the need for credential hygiene and tightly scoped access policies.
AI Investigations Try to Compress the Triage Cycle
GuardDuty AI-powered investigations, currently in preview, automatically examine findings and related account activity to distinguish likely threats from benign behavior. AWS says the system considers up to 90 days of related activity, affected resources, threat indicators, knowledge graphs, and threat intelligence.Each investigation produces a disposition assessment, confidence score, supporting evidence, MITRE ATT&CK classification, and recommended action. Those recommendations can include suppressing an alert, containing an affected resource, or beginning remediation.
The potential benefit is reduced triage time, especially in large AWS Organizations where one suspicious event may touch several accounts and services. The risk is that administrators begin treating an AI-generated disposition as a final verdict rather than an aid to investigation.
Confidence scoring is not proof. Security teams evaluating the preview should compare its conclusions against analyst decisions, track false-positive and false-negative rates, and require human review before destructive containment actions are automated. The feature’s value will depend less on how polished its summaries appear and more on whether its evidence reliably leads responders back to the relevant CloudTrail events, identities, and resources.
Security Hub Builds an Organization-Wide AI Asset Map
The generally available Security Hub AI inventory addresses a more basic problem: many organizations do not have a complete record of the AI systems their teams have deployed.For AWS-managed services, the inventory uses AWS Config resources to catalog workloads across Amazon Bedrock, SageMaker, and AgentCore. Runtime analysis can also find models hosted on EC2, ECS, and EKS, as well as external model endpoints contacted by AWS workloads.
Security Hub then maps those assets to supporting compute, networking, IAM roles, and data stores. It also correlates the inventory with signals such as GuardDuty findings, allowing an anomalous model invocation to be viewed alongside the infrastructure and identities connected to it.
This could expose the AI equivalent of shadow IT: an experimental SageMaker endpoint left running, a Bedrock agent created for a proof of concept, or a Lambda function quietly calling an external model API. In a large organization, these deployments can spread across hundreds of accounts before the central security team establishes governance.
The inventory is included in the Security Hub Essentials plan at no additional cost, according to AWS. That removes one barrier to adoption, although customers still need suitable AWS Config coverage and runtime visibility if they expect the catalog to be complete.
AWS Wants Correlation, Not Another Dashboard
The broader strategy ties native AWS and Azure monitoring to Security Hub Extended, which now includes 21 selected partners across endpoint, identity, email, browser, network, data, cloud, AI, and security operations. The list includes CrowdStrike, CyberArk’s Idira, Okta, Proofpoint, SailPoint, SentinelOne, Splunk, Varonis, and Zscaler.Partner findings are emitted using the Open Cybersecurity Schema Framework, or OCSF, and aggregated in Security Hub. AWS says it is working toward correlating signals from different products into a single exposure or attack path rather than presenting endpoint, identity, and cloud alerts as unrelated incidents.
That is the most ambitious part of the announcement—and the least complete. The Azure assessments and AI inventory are usable capabilities now, but broad cross-vendor correlation depends on the depth, consistency, and timeliness of each integration. Normalizing alerts into OCSF is a useful foundation; producing trustworthy attack-path analysis from them is a considerably harder engineering and operational problem.
For mixed Microsoft and AWS estates, the July 14 release creates a practical new option: Azure risks can now enter existing Security Hub workflows, while AWS-native AI workloads gain dedicated inventory and threat detection. The next test is whether AWS can expand Azure resource coverage and turn its growing collection of standardized findings into fewer, better incidents rather than one more centralized pile of alerts.
References
- Primary source: Amazon Web Services (AWS)
Published: 2026-07-14T19:16:57+00:00
Security Hub adds AI workload protection and multicloud support for Microsoft Azure | AWS Security Blog
Security Hub is our foundation for full-stack enterprise security across clouds. It centralizes your security operations and turns raw signals into prioritized insights, so your team spends its time managing real risk instead of stitching tools together. Today that foundation grows in two...aws.amazon.com - Independent coverage: SiliconANGLE
Published: 2026-07-14T19:00:35+00:00
AWS Security Hub expands coverage to Microsoft Azure and beefs up AI protections - SiliconANGLE
AWS Security Hub expands coverage to Microsoft Azure and beefs up AI protections - SiliconANGLE
siliconangle.com
