Multi-cloud security is not the same as single-cloud security done twice. The threat surface expands, the governance tools differ between providers, and the places where misconfiguration hides are different in each environment. Below are the seven practices we consider non-negotiable when operating across both platforms.
1. Unified security logging
Security events that live in separate systems are effectively invisible. AWS CloudTrail, Azure Activity Logs, Kubernetes audit logs, application security events: all of these need to flow into a single platform where they can be correlated and queried together. Datadog Cloud SIEM is one approach; a centralised SIEM with connectors for both clouds is another.
The minimum viable outcome: a security analyst or on-call engineer can search for an IP address, a user identity, or a resource name and get results from both clouds in one query. If that is not possible, you will miss threat patterns that span the boundary.
2. Cloud Security Posture Management (CSPM)
CSPM tools continuously check your cloud configuration against security best practices and flag deviations: public S3 buckets, storage accounts with wide access, security groups that allow inbound traffic from 0.0.0.0/0, encryption not enabled at rest. These misconfigurations are the most common source of preventable cloud security incidents.
Both AWS Security Hub and Microsoft Defender for Cloud provide baseline CSPM. Enable them, route findings to your central observability platform, and set up processes to review and remediate findings on a defined cadence. A finding that sits unreviewed for three months provides no protection.
3. Least-privilege identity
Covered in detail in our cross-cloud identity management guide, but worth restating as a security practice: every identity, human and machine, should have the minimum permissions necessary for its function. Review standing admin access quarterly. Remove access keys that have not been used in 90 days. Enforce MFA at the identity provider level, not as a per-account setting that can be worked around.
4. Network segmentation
Do not put everything in a flat network. Use VPCs and subnets in AWS, Virtual Networks in Azure, and network security groups or security policies to restrict traffic flow to what is explicitly needed. East-west traffic inside your cloud environment is as important to control as north-south traffic from the internet.
Private endpoints for managed services (databases, storage, APIs) mean those services are not reachable from the public internet at all, which eliminates a significant class of exposure. This is standard practice for environments handling sensitive data and should be the default for any new workload you deploy.
5. Vulnerability management with observability
Vulnerability scanning at build time (container images, infrastructure-as-code) is table stakes. The harder part is runtime visibility: knowing which vulnerable components are actually running in production right now, not which components were present when the image was built last month. Datadog's cloud workload security and container scanning capabilities provide this runtime view.
Without runtime visibility, patching is reactive and often slower than it needs to be. With it, you can prioritise based on actual exposure rather than theoretical risk scores.
6. Patch cadence and automation
Unpatched operating systems and runtimes are a consistent factor in cloud incidents. Define a patch cadence for your environment, automate it where possible (AWS Systems Manager Patch Manager, Azure Update Manager), and have a fast-track process for critical vulnerabilities. A critical CVE that drops on a Friday should not wait until Monday's sprint planning to be assessed.
Document your patch SLAs and measure against them. Environments that do not measure patch cadence tend to have much longer actual patch cycles than their stated policies suggest.
7. Incident response planning that covers both clouds
Your incident response runbooks need to cover both cloud environments, not just the one that gets more attention. This means: knowing who can access each environment in an emergency, having break-glass procedures for both, and having tested the response process before you need it.
Cloud incident response also benefits significantly from good observability. When we apply Datadog-powered monitoring to customer environments and something goes wrong, engineers start from a correlated picture rather than individual log files. The practical result is a 60% reduction in mean time to resolution compared to unmonitored environments. That difference is most visible in security incidents where speed of containment matters most.
For AI-powered workloads, consider dedicated AI incident response planning that covers the specific failure modes of AI components alongside traditional cloud infrastructure failures.