Top 24 Cloud Security Best Practices for 2026

If you’ve spent any time managing Windows servers, hardening Linux boxes, or untangling firewall rules at 2:00 AM, you know that security has always been complex. Moving to the cloud doesn’t make it simple, it makes it different.

The attack surface shifts, the tooling changes, and the shared responsibility model mean you must rethink assumptions that may have served you well for years.

This post distills what I’ve learned as a security engineering director and, before that, as a consultant who spent years in the trenches doing Windows and Linux administration, networking, and security across hybrid environments into a practical framework for cloud security. It follows the major cloud security best practices that any serious organization should address in cloud security.

Before diving into tools and configurations, it’s worth grounding ourselves in the principles that should guide every cloud security decision.

Cloud security is the set of policies, controls, and technologies used to protect cloud-hosted data, applications, and infrastructure from unauthorized access, misconfiguration, and attacks. It covers how you secure what you run in the cloud, plus how you manage identities, data protection, and operational risk.

Common cloud security challenges

Here are the cloud security challenges we see most often, especially as teams scale across accounts, regions, and tools:

• Misconfigurations at scale – Small mistakes (public access, open ports, no encryption) become inevitable when teams move fast.
• IAM sprawl and over-permissioning – Too many roles, unclear ownership, and “temporary” broad access that quietly becomes permanent
• Secrets exposure and weak rotation – Leaked keys in repos/CI logs, shared secrets across environments, and slow or manual rotation
• Limited visibility and poor asset inventory – If you can’t answer “what exists, who owns it, and what changed,” you can’t secure it.
• Drift and shadow resources – Console fixes and manual changes break parity with infrastructure as code, often discovered during incidents or audits.
• Inconsistent guardrails and policy enforcement – Policies live in docs, not workflows, so enforcement depends on who’s deploying and how experienced they are.

Cloud security best practices come down to two things: clear ownership (the shared responsibility model) and repeatable controls (implemented in code, monitored continuously).

Here’s a practical checklist you can apply in any major cloud:

1. Apply the principle of least privilege.
2. Adopt a defense-in-depth strategy.
3. Model threat actors and trust boundaries.
4. Choose the right cloud delivery model.
5. Understand the cloud shared responsibility model.
6. Adopt a risk-based approach.
7. Use data classification as the foundation.
8. Encrypt data and manage keys securely.
9. Prevent leakage and manage the lifecycle.
10. Maintain continuous cloud asset visibility and ownership.
11. Harden compute assets with secure baselines.
12. Prevent and remediate configuration drift.
13. Centralize identity management and enforce MFA universally.
14. Enforce RBAC based on job responsibilities.
15. Secure and manage machine identities.
16. Monitor for identity-based threats and high-risk actions.
17. Integrate continuous vulnerability scanning into your CI/CD pipeline.
18. Prioritize remediation based on exploitability.
19. Adopt a zero-trust, hostile-network mindset.
20. Enforce workload-level micro-segmentation with defense in depth.
21. Secure connectivity, encryption-in-transit, and controlled exposure.
22. Centralize your logging.
23. Build detection rules.
24. Develop and rehearse incident response playbooks.

The principle of least privilege is simple to state and difficult to implement: Every identity, human, or machine should have only the permissions necessary to perform its function, and nothing more.

In cloud environments, this becomes both more critical and more challenging because of the sheer volume of permissions available. AWS IAM alone has thousands of discrete actions across hundreds of services.

Start with deny-by-default policies and grant access incrementally. Use tools like AWS IAM Access Analyzer and Azure AD Privileged Identity Management to identify and prune excessive permissions over time.

Every engineer will tell you that no single control is sufficient. Defense in depth layers multiple security mechanisms so that if one fails, others still protect your assets.

In the cloud, this means combining network controls (security groups, NACLs), identity controls (MFA, conditional access), application-level controls (WAF, input validation), and data-level controls (encryption, tokenization).

Think of it as concentric rings: Your perimeter controls are the outer ring, but you should assume they’ll eventually be bypassed. The question is whether you have enough inner rings to contain the damage.

Before you can defend a system, you need to understand who might attack it and how. This is where threat modeling comes into play. Using frameworks like STRIDE or PASTA helps you systematically identify what you’re protecting against.

Trust boundaries are where data or execution crosses from one trust level to another: from the internet to your VPC, from one microservice to another, or from a developer’s laptop to your CI/CD pipeline.

Document these boundaries explicitly. Architecture diagrams that include trust boundaries are one of the most underrated security tools. They make implicit assumptions visible and help teams reason about where controls are needed.

The delivery model you choose (IaaS, PaaS, or SaaS) fundamentally shapes your security posture. With IaaS, you’re responsible for the OS, middleware, and application security.

• With PaaS, the provider handles more of the stack, but you still own data and access controls.
• With SaaS, your control is limited to configuration and identity management.

Understanding which model you’re operating in for each workload is essential, because it determines where your security responsibilities begin and end.

Every major cloud provider publishes a shared responsibility model, and yet misunderstanding it remains one of the most common sources of cloud security failures. The provider secures the infrastructure “of” the cloud; you secure what you put “in” the cloud.

In practice, this means the provider ensures hypervisors are patched and data centers are physically secure, but you are responsible for configuring security groups correctly, encrypting data at rest, managing IAM policies, and keeping your workloads patched.

Cloud security is ultimately about managing risk, not eliminating it. Adopt a risk-based approach that considers likelihood, impact, and your organization’s risk appetite. Not every finding is critical, and not every vulnerability needs to be patched immediately, but you need a defensible process for making those decisions.

Use frameworks like NIST CSF or ISO 27005 to structure your risk management program, and ensure it accounts for the dynamic nature of cloud environments where assets and configurations change constantly.

Data is the reason your cloud environment exists, and protecting it should be the central organizing principle of your security program.

Start with a data classification scheme. Not all data requires the same level of protection, and treating everything as top-secret is both expensive and impractical.

Classify data by sensitivity, public, internal, confidential, restricted, and apply controls proportionally. This classification should drive decisions about encryption standards, access controls, retention policies, and where data is permitted to reside geographically.

Encrypt data at rest and in transit. In 2026, there is no excuse for unencrypted data stores. Use provider-managed keys (AWS KMS and Azure Key Vault) as a baseline, and customer-managed keys for your most sensitive workloads.

Implement key rotation policies and audit key usage. Pay particular attention to envelope encryption for large data sets and ensure your key hierarchy is well documented. Losing access to an encryption key is functionally equivalent to losing the data itself.

Implement data loss prevention (DLP) policies that detect and prevent sensitive data from leaving your control boundary. This includes monitoring for sensitive data in logs, backups, and development environments.

Places where it often leaks unintentionally. Modern DLP tools can scan cloud storage, databases, and even SaaS applications for patterns like credit card numbers, social security numbers, or custom patterns specific to your business. Pair DLP with data access logging so you have an audit trail of who accessed what, when, and from where.

Don’t overlook data lifecycle management. Define retention policies that comply with your regulatory requirements and automate enforcement. Data that should have been deleted six months ago is still a liability if it’s breached.

Use lifecycle rules for storage services (S3 lifecycle policies and Azure Blob Storage tiering) to automatically transition or expire data based on your classification.

You can’t secure what you don’t know about. Cloud asset management is challenging because assets can be ephemeral instances that spin up and down. For example, containers live for minutes, and serverless functions execute on demand.

Implement a cloud asset inventory that updates continuously. Cloud Security Posture Management (CSPM) tools like AWS Security Hub, Microsoft Defender for Cloud, or third-party solutions can provide this visibility.

Tag every resource with owner, environment, data classification, and cost center at a minimum. Enforce tagging through service control policies or tag policies that prevent resource creation without required tags.

Harden your compute assets using CIS Benchmarks as a baseline.

• For IaaS workloads, use hardened AMIs or golden images built through an automated pipeline that applies security baselines, removes unnecessary packages, and disables default accounts.
• For containers, scan images at build time and in registries, and enforce admission policies that reject unscanned or vulnerable images.
• For serverless, minimize function permissions and set appropriate timeouts and memory limits to reduce the impact of a compromised function.

Configuration drift is a silent threat. An instance that was compliant at deployment can become non-compliant within days as teams make ad-hoc changes.

Use a configuration management tool such as AWS Systems Manager, Azure Automation, or traditional tools like Ansible to enforce the desired state and detect drift.

Pair this with automated remediation where appropriate: if a security group rule is added that violates policy, automatically revert it and notify the team.

Identity is the new perimeter. In cloud environments, network boundaries are porous and dynamic, which makes identity the primary control plane for access to resources.

Centralize identity management. Use a single identity provider (IdP) federated across your cloud accounts. Enforce multi-factor authentication universally so there is no role, service account, or emergency break-glass process that shouldn’t be behind MFA.

Phishing-resistant MFA methods, such as FIDO2 security keys or passkeys, should be your standard for privileged users. SMS-based MFA is better than nothing, but it’s vulnerable to SIM-swapping and interception.

Implement role-based access control (RBAC) aligned with job functions, and supplement it with attribute-based access control (ABAC) where finer-grained access is needed.

Use service control policies (SCPs in AWS) or management group policies (Azure) to set guardrails that no individual account or subscription can override.

Don’t forget machine identities. Service accounts, API keys, and workload identity credentials often outnumber human users by an order of magnitude, and they’re frequently over-privileged and poorly rotated.

Use workload identity federation (AWS IAM Roles Anywhere, Azure Managed Identities) to eliminate long-lived credentials wherever possible. For service accounts that must exist, enforce automatic rotation and monitor for usage anomalies.

Monitor for identity-based threats: impossible travel detections, unusual API call patterns, dormant account usage, and privilege escalation attempts. These are often the first indicators of compromised credentials.

Set up alerts for high-risk actions, such as creating new IAM users, attaching administrator policies, or disabling CloudTrail logging. These are techniques attackers commonly use to establish persistence.

Vulnerability management in the cloud requires a shift from periodic scanning to continuous assessment. Traditional scan-and-patch cycles that work on a monthly cadence are too slow for environments where infrastructure changes daily.

Integrate vulnerability scanning into your CI/CD pipeline:

• Scan infrastructure-as-code templates (Terraform, CloudFormation, Bicep) before they’re deployed
• Scan container images at build time and in registries
• Scan running workloads with agent-based or agentless tools that account for the ephemeral nature of cloud compute

Read more: Vulnerability Remediation: Process & Best Practices

Prioritize remediation based on exploitability, not just CVSS scores. A critical vulnerability in a workload with no internet exposure and strong compensating controls is a lower priority than a high-severity vulnerability in a public-facing application with known exploits in the wild.

Cloud networking is fundamentally different from traditional networking, and the security model must adapt accordingly. The concept of a trusted internal network no longer applies. Assume every network segment is hostile and enforce zero-trust principles.

Zero trust in practice means that every request is authenticated and authorized regardless of where it originates.

In network terms, zero trust translates to micro-segmentation at the workload level, not just at the subnet level. Each workload should only be able to communicate with the specific services it depends on. Use security groups as your primary micro-segmentation tool, and layer network ACLs as a secondary backstop for broader subnet-level controls.

Before defining restrictive policies, use VPC flow logs and network traffic analysis to understand actual communication patterns. This prevents you from inadvertently breaking legitimate traffic while giving you a data-driven foundation for your segmentation strategy.

For connectivity between cloud and on-premises environments, use dedicated private connections (AWS Direct Connect, Azure ExpressRoute) rather than VPN tunnels where performance and security requirements warrant it. Encrypt all traffic in transit, even within your VPC.

Defense in depth applies to the network layer, too. Consider service-mesh architectures (Istio, Linkerd) for microservice communication, which provide mutual TLS, traffic management, and observability without requiring application code changes.

Implement DNS-level security controls and use private DNS zones to prevent data exfiltration via DNS tunneling. Deploy web application firewalls for public-facing applications and use DDoS protection services for internet-facing endpoints.

Don’t neglect egress filtering either. Controlling what traffic can leave your VPC is just as important as controlling what comes in.

Many data exfiltration and command-and-control techniques rely on outbound connectivity that unrestricted egress makes trivially easy.

The best preventive controls in the world won’t stop every attack. Your detection, response, and recovery capabilities determine whether an incident is a minor event or a catastrophic breach.

Centralize your logging. Aggregate cloud-native logs (CloudTrail, Azure Activity), VPC flow logs, application logs, and OS-level logs into a SIEM or log analytics platform.

Ensure logs are immutable and retained for a period that meets both your compliance requirements and your investigation needs.

Build detection rules that map to the MITRE ATT&CK Cloud Matrix. Focus on high-fidelity detections for the most impactful techniques:

• Initial access via compromised credentials
• Privilege escalation through role assumption
• Persistence via backdoor accounts or modified Lambda functions
• Data exfiltration via unusual S3 or storage access patterns

Develop and rehearse incident response playbooks specific to cloud scenarios. A compromised EC2 instance requires a different response than a compromised IAM access key, and both are different from a misconfigured S3 bucket.

Automate containment actions where possible, isolating a compromised instance by modifying its security group, for example, to reduce response time.

Plan for recovery. Ensure your backups are in a separate account and region from your production workloads. Test your restore process regularly. A backup you’ve never tested is a hope, not a plan.

Cloud security fundamentals don’t change across deployment models. Identity, network boundaries, data protection, visibility, and change control always matter.

What does change is where your risk concentrates: public cloud tends to amplify misconfiguration and permission sprawl, private cloud shifts more responsibility for hardening and patching to you, hybrid adds “gaps” between environments, and multicloud increases inconsistency across IAM, logging, and guardrails.

The best way to stay secure across any model is to standardize a few non-negotiables: enforce least privilege and short-lived access, apply policy as code so guardrails are consistent, centralize audit logs/run history for incident response, and continuously detect configuration drift so “temporary” ClickOps doesn’t become permanent risk.

A platform like Spacelift can help your organization manage cloud infrastructure more efficiently. Spacelift is an infrastructure orchestration platform that supports tools like OpenTofu, Terraform, Ansible, Pulumi, Kubernetes, CloudFormation, and more.

Security is one of Spacelift’s top priorities, with features such as policy as code, encryption, Single Sign-On (SSO), MFA, and private worker pools built into the product. Spacelift is SOC 2 Type II audited and provides compliance and security artifacts, including GDPR resources and its DPA, through the Spacelift Trust Center.

It is also the first IaC orchestration platform to receive FedRAMP authorization, delivering flexible, policy-driven automation to federal agencies and contractors seeking secure, compliant infrastructure workflows.

The power of Spacelift lies in its fully automated hands-on approach. Once you’ve created a Spacelift stack for your project, changes to the IaC files in your repository will automatically be applied to your infrastructure. 

Spacelift’s pull request integrations keep everyone informed of what will change by displaying which resources are going to be affected by new merges. Spacelift also allows you to enforce policies and automated compliance checks that prevent dangerous oversights from occurring.

Spacelift includes drift detection capabilities that periodically check your infrastructure for discrepancies compared to your repository’s state. It can then launch reconciliation jobs to restore the correct state, ensuring your infrastructure operates predictably and reliably.

With Spacelift, you get:

• Policies to control what kind of resources engineers can create, what parameters they can have, how many approvals you need for a run, what kind of task you execute, what happens when a pull request is open, and where to send your notifications
• Stack dependencies to build multi-infrastructure automation workflows with dependencies, having the ability to build a workflow that, for example, generates your EC2 instances using Terraform and combines it with Ansible to configure them
• Self-service infrastructure via Blueprints enabling your developers to do what matters – developing application code while not sacrificing control
• Creature comforts such as contexts (reusable containers for your environment variables, files, and hooks), and the ability to run arbitrary code
• Drift detection and optional remediation

If you want to learn more about Spacelift, create a free account today or book a demo with one of our engineers.

Cloud security is a continuous practice. The threat landscape evolves, cloud providers release new services and features weekly, and your own environment grows in complexity over time. What matters is having the right principles, the right processes, and a culture that treats security as a shared responsibility across the entire engineering organization.

If I’ve learned anything from years of moving between on-prem, hybrid, and cloud-native environments, it’s that the fundamentals don’t change: Know your assets, control your access, layer your defenses, and be ready when something goes wrong. The tools are different, but the discipline is the same.

Start where you are. Pick the domain where you have the most risk and the least visibility and focus there first. Perfect security is a myth; meaningful improvement is not.