25 Cloud Security Tips and Best Practices

A developer creates an access key to test a script. The test ends, the developer moves to another project, and the key stays active. Two years later, that forgotten key can still read your production data. No one is watching it. An attacker who finds it won’t wait.

Many cloud breaches begin with a small gap like this one. The cloud security tips in this guide help you find those security gaps and close them before they lead to a data breach.

Below are 25 cloud security tips and best practices for teams using AWS, Microsoft Azure, or Google Cloud. Each tip tells you what to do, which tool to use on your cloud provider, and how to check that it worked. The summary table shows each tip’s priority, so you know where to begin. If you’re new to the topic, our guide on what cloud security is explains the basics first.

Short on time? Start with three quick wins to protect your data today. Turn on multifactor authentication that resists phishing for every admin, block public access to your cloud storage, and switch on logging in every account.

Why Cloud Security Tips and Best Practices Matter

Most cloud attacks don’t break the provider’s systems. They slip through gaps on the customer’s side, and cloud security best practices close those gaps first.

Google Cloud’s Threat Horizons Report found that in late 2025, unpatched outside software caused 44.5% of break-ins, weak or missing credentials 27.2%, and wrong settings 21%. Attackers are also faster. In one case, they were exploiting a newly announced vulnerability within about 48 hours.

The damage adds up fast. IBM’s 2026 Cost of a Data Breach Report puts the average breach at $4.99 million, and only 37% of breached companies encrypt sensitive data both at rest and in transit.

The cloud security tips below fix these security threats first. For warning signs of each security risk, see our cloud security guide.

All 25 Cloud Security Practices

Use this table to plan your work. Start with the quick wins, since they take hours and block the most common attacks. Then work through the foundational security practices over the next few months.

We set each priority based on two things. How much risk the tip removes, and how long it takes a small team to finish.

Finishing the seven quick wins first shrinks your attack surface fast, even before the bigger projects begin.

What Your Cloud Provider Already Secures by Default

Every major cloud service provider has turned on stronger security features by default in recent years. That helps, but there’s a catch. Most of these defaults only apply to things created after the change, so older accounts and storage keep their old settings until you fix them.

Two gaps remain even on new accounts. 

First, a required second step doesn’t always stop phishing. AWS accepts virtual authenticator apps and hardware codes as well as security keys and passkeys, and codes typed into a fake login page can still be stolen.

Second, these rules mostly cover people. Azure’s rule applies to all users, including scripts that sign in with a user account instead of an application ID, so keys used by apps and services still need their own controls.

Treat these defaults as basic security, not a finished job. Tips 4, 7, and 13 show how to check older resources and close what the defaults miss, so your security posture is the same across every account.

Securing the Cloud From Day One

These first three tips set the ground rules. Get them right, and every other tip in this list becomes easier to apply.

1. Know Your Side of the Shared Responsibility Model

Your provider secures its buildings, hardware, and core platform. You secure your data, your users, and your settings. That split is called the shared responsibility model, and trouble starts when a team assumes the provider covers something it doesn’t.

The line moves with each cloud service you use. On AWS, customers running an EC2 server manage its operating system, including updates and security patches, plus the security group firewall. With services like S3 and DynamoDB, AWS runs the operating system and platform, while you still manage your data, encryption options, and permissions.

Try this. Make a simple sheet of every service you use. For each one, note who patches it, who configures it, and who backs it up. Any “not sure” answer needs an owner this week.

Watch out for recycle bins in SaaS apps. SharePoint keeps deleted items for 93 days, then deletes them for good. That’s a safety net, not a backup. The more a provider runs for you, the less you patch, but no type of cloud ever takes your data or user access off your plate.

2. List Every Account and the Person Who Owns It

You can’t protect what you don’t know exists. That’s why the CIS Controls start with an inventory of company assets and software.

Start with money, not scanners. Search company card statements and cloud bills for charges you don’t recognize. This often turns up old trial accounts and test projects, and it gives you real visibility into your team’s cloud usage.

Then pull a full resource list with AWS Resource Explorer, Azure Resource Graph, or Google Cloud Asset Inventory. Tag every resource with an owner and an environment, such as production or test.

Check your DNS records too. A record that points to a deleted cloud resource is called a dangling DNS entry, and it can let an attacker take over your subdomain and send your visitors to a harmful site. Old records like these are easy potential attack vectors to miss.

Quick check. Can you name the owner of every account, subscription, and project, including old trials?

3. Set Up a Landing Zone Before Migrating to the Cloud

A landing zone is a ready made account layout with security built in. Set it up before migrating to the cloud, because fixing the design later means moving your workloads twice.

Each provider gives you a starting point. AWS offers Control Tower, Azure offers landing zones, and Google Cloud offers its enterprise foundations blueprint with Terraform code you can adapt.

Split your cloud infrastructure into separate accounts for production, development, logs, and security tools. If one account is breached, the others stay walled off.

Keep your top account nearly empty. AWS advises storing all resources in other accounts, partly because service control policies can’t restrict users or roles in the management account.

Watch out for old permissions. Teams often copy broad on-premises admin groups into the cloud. Start with fresh, narrow roles and security controls built for the new setup.

Tighten Identity and Access Management

Most cloud attacks start with a login, not a hack. Strong identity and access management decides who gets in and what they can touch once inside.

4. Use Multifactor Authentication That Resists Phishing

Not all multifactor authentication is equal. CISA warns that some types can be beaten by phishing, push bombing, or SIM swaps. Push bombing means flooding a user with login prompts until they tap “approve” just to make them stop.

CISA points to FIDO/WebAuthn and smart card methods as the strong options. For most teams, that means passkeys or hardware security keys.

Where to set it. AWS IAM Identity Center, Microsoft Entra Conditional Access, and Google Cloud’s 2 Step Verification settings.

Start with admins and anyone who can change billing or security settings. If some users still need app prompts, turn on number matching, which makes them type a code shown on the login screen.

5. Give Each Identity Only the Access It Needs

The principle of least privilege means every user and app gets the smallest permission set that lets it do its job. If an account is stolen, the damage stays small.

You don’t have to guess what to remove. IAM Access Analyzer reviews up to 90 days of CloudTrail history and builds a policy from what the user or role actually used. Google Cloud’s IAM Recommender and Microsoft Entra Privileged Identity Management help in the same way.

Watch out for “temporary” admin rights. Use time limited access so the extra rights end on their own.

6. Lock Down Root and Global Admin Accounts

These accounts can do anything, so they should almost never be used.

On AWS, delete root access keys and protect the root user with a security key. For companies with many accounts, AWS recommends managing root access centrally and removing root credentials from member accounts.

On Azure, keep two emergency access accounts with strong sign in methods, and store their details offline.

Quick check. Sign in with one of these accounts. If no alert reaches your security team, set one up today.

7. Replace Permanent Keys for Cloud Identities

Scripts, servers, and pipelines often use saved keys that never expire. Google Cloud service account keys, for example, don’t expire unless you set a policy. Worse, a key keeps working after the person who made it leaves.

Swap these keys for short lived credentials that renew on their own. Use IAM roles on AWS, managed identities on Azure, and Workload Identity Federation on Google Cloud. Build pipelines like GitHub Actions can sign in through OIDC, so no key is stored at all.

Quick check. Run the AWS IAM credential report and flag any key older than 90 days or unused for 90 days.

8. Review Access Quarterly and Offboard Same Day

Good access management is a habit, not a one time setup. Review who has access every quarter and ask each account owner to sign off.

When someone leaves, a password reset isn’t enough. Many cloud apps issue their own session tokens, and Microsoft notes Entra ID can’t directly cancel a session token that an app issued. Microsoft recommends automatic deprovisioning so access is removed inside each app too.

Try this. Connect your apps to single sign on with automatic provisioning. Then one switch can prevent unauthorized access everywhere at once.

Watch out for contractor and vendor accounts, which often stay active long after a project ends.

Cloud Data Security and Encryption

Your data is what attackers want most. These four tips focus on data protection, from finding sensitive files to making sure you can recover them.

9. Map Sensitive Data for Better Data Protection

You can’t protect sensitive data if you don’t know where it sits. Data in the cloud spreads fast through exports, copies, and test systems.

Scan for the different types of data you hold, such as customer records, payment details, and health information. Then label each store by how sensitive it is.

Where to scan. Amazon Macie, Microsoft Purview, or Google Cloud Sensitive Data Protection.

Check the hidden spots. Database snapshots, app logs, analytics exports, and AI training files often hold real customer data with weaker data security than the main database.

10. Encrypt Data at Rest and in Transit

Turn on encryption for stored data and for data moving between systems. Require TLS 1.2 or newer for all traffic.

Default encryption has a limit. Anyone with read access still sees plain data, because the provider unlocks it for them. Customer managed keys add a second lock, since reading the data also needs permission to use your key.

Your own keys also give you an emergency switch. In AWS KMS, a key scheduled for deletion stops working right away, with a waiting period of 7 to 30 days before it’s gone, and data locked with a deleted key can’t be recovered. Use this carefully.

For your most important keys, use hardware security modules such as AWS CloudHSM, Azure Managed HSM, or Google Cloud HSM.

11. Keep Passwords and Keys Out of Your Code

Store passwords and API keys in AWS Secrets Manager, Azure Key Vault, or Google Secret Manager, never in code.

If a key leaks, deleting it from your code isn’t enough. It stays in your Git history and in any copies. Revoke the key first, then clean up.

Secrets also hide in less obvious places. HashiCorp warns that local Terraform state is stored as plain text, including any secret values in your setup. Keep state files in encrypted remote storage and out of Git. Check build logs and container images too.

Try this. Turn on GitHub secret scanning with push protection to block keys before they reach your repository.

12. Store Backups Attackers Cannot Delete

Ransomware is common, and attackers often go after backups before anything else. IBM found that 39% of breached companies reported a ransomware incident, up from 34% the year before.

Keep three copies of your data, on two types of storage, with one copy offsite. Store backups in a separate account with its own login, and turn on immutability so no one can change or delete them early.

Where to set it. AWS Backup Vault Lock, Azure Backup immutable vaults, or Google Cloud Backup and DR backup vaults. Don’t rely on versioning in cloud storage alone, since someone with admin rights can suspend it.

Quick check. Restore a full system twice a year and time it. A backup you’ve never tested may not work when you need it.

Cloud Network Security

Good network security limits who can reach your systems and how far an intruder can move once inside.

13. Block Public Storage to Secure Your Cloud

Turn on public access blocks for the whole account or organization, not one bucket at a time. That’s the fastest way to secure your cloud storage.

Where to set it. S3 Block Public Access on AWS, “Allow Blob anonymous access” set to Disabled on Azure, and public access prevention on Google Cloud.

Watch out for “allAuthenticatedUsers” in Google Cloud. It sounds safe, but it gives access to anyone with any Google account, not just your staff.

Also close SSH and RDP ports that face the internet. Use AWS Systems Manager Session Manager, Azure Bastion, or Google Cloud Identity Aware Proxy for admin access instead.

14. Separate Networks and Filter Outbound Traffic

Keep production apart from development and testing, and put databases in private subnets. If one system is breached, the attacker can’t easily reach the rest. This shrinks your attack surface.

Control what goes out, not just what comes in. Use security groups on AWS, network security groups on Azure, and VPC firewall rules on Google Cloud to allow only the outbound traffic each system needs.

On AWS, require IMDSv2 for your servers. This newer version of the metadata service helps block SSRF attacks, where a flaw tricks a server into handing over its temporary credentials. You can set it as the default for new servers with one setting per region, though existing servers keep their current setting, so update those separately.

15. Strengthen Cloud Application Security at the Edge

Put a web application firewall in front of your cloud applications. AWS WAF, Azure Web Application Firewall, and Google Cloud Armor can block common attacks, filter bots, and limit how many requests one user can send.

A WAF has limits, though. The top risk in the OWASP API Security Top 10 is broken object level authorization, where a logged in user can open someone else’s records just by changing an ID. A firewall can’t spot this, because the request looks normal.

Quick check. Log in as one test user and request a record that belongs to another test user. If it opens, fix the access check in your code.

How to Protect Cloud Workloads?

Cloud workloads are the servers, containers, and functions that run your code. These tips help you secure them before and after they go live.

16. Harden Every Workload Before It Ships

Start each workload from a small, current base image. Fewer packages mean fewer things to patch.

Before release, scan every image for known flaws and block any that fail. Run containers as a non root user with a read only file system where you can. On Kubernetes, apply the Pod Security Standards.

Watch out for old images. New flaws show up in base images even when your code doesn’t change, so rebuild and rescan on a set schedule, such as every week.

Try this. Sign your images and allow only signed ones to run. Tools like Sigstore, or Binary Authorization on Google Kubernetes Engine, handle this.

17. Build Security Best Practices Into CI/CD

Add security checks to every step of the software development lifecycle, so problems get caught while they’re still cheap to fix. This is often called code to cloud security.

Integrate these scans into your build pipeline. Check infrastructure templates with free tools like Checkov or Trivy, scan open source packages, and fail any build that breaks a rule.

The pipeline itself needs protection too. In March 2025, attackers changed version tags on the popular GitHub Action tj-actions/changed-files so they pointed to harmful code, which leaked secrets into workflow logs. Teams that referenced tags like “v45” pulled in the bad code without knowing.

Fix. Pin every outside action to its full commit ID, not a version tag, and review updates before you accept them.

18. Manage Each Vulnerability by Attack Risk

Scanners often report thousands of flaws. You can’t fix them all at once, so fix the ones attackers are most likely to use first.

Rank each vulnerability with three questions.

1. Is it on CISA’s Known Exploited Vulnerabilities catalog? That means attackers already exploit it.
2. What is its EPSS score? FIRST’s scoring system estimates how likely a flaw is to be used soon.
3. Does the system face the internet?

A flaw that scores high on all three gets patched today. A low scoring flaw on an internal test server can wait for the normal cycle.

Where to scan. Amazon Inspector, Microsoft Defender for Cloud, or Google Cloud Security Command Center.

Watch out for rushed patches. Test fixes outside production first, so solving one security issue doesn’t create an outage.

Cloud Monitoring and Response to Security Threats

You can’t stop what you can’t see. These tips help you spot security threats early and respond fast when something goes wrong.

19. Turn On Logging in Every Account

Some of the most useful logs are off by default or kept for a short time. Check these gaps first.

Also know this. In Google Cloud, resources opened to allUsers or allAuthenticatedUsers don’t create audit logs, so public access leaves no trail. That’s one more reason to block it.

Try this. Send all logs to a separate, locked account, and set an alert for anyone who stops or deletes logging.

20. Switch On Your Provider’s Security Solutions

Every major provider includes threat detection you can turn on today. Start with the security solutions you already pay for before buying more cloud security tools.

Where to find them. Amazon GuardDuty, Microsoft Defender for Cloud, and Google Security Command Center.

Turn them on in every region, not just the ones you use. Attackers often launch servers in regions nobody watches. If you never use a region, block it with an organization policy.

Watch your bill too. A sudden cost spike often means someone is mining crypto on your account. Set up AWS Cost Anomaly Detection, Azure cost alerts, or Google Cloud budget alerts as a free early warning system alongside your security services.

21. Automate Cloud Security Configuration Checks

People make mistakes when they change settings by hand. Automate the rules instead, so risky settings get blocked before they exist.

Use three layers.

1. Block. AWS Service Control Policies, Azure Policy, and Google Cloud Organization Policy stop risky changes, such as creating a public bucket.
2. Detect. Cloud security posture management tools flag settings that drift from your baseline.
3. Fix. Automatic fixes close common problems, like public storage, within minutes.

Start new rules in audit mode. Watch what they would block for a week or two, then turn on enforcement so you don’t break production.

If you run containers across several providers, cloud native application protection platforms combine these checks with workload scanning in one view. For Microsoft 365 and Google Workspace, use CISA’s free SCuBA secure configuration baselines.

22. Rehearse Your Cloud Incident Response Plan

Write short playbooks for your most likely security incidents, such as a leaked key, a hijacked admin account, and ransomware. Base them on NIST SP 800-61 Rev. 3 and map them to the MITRE ATT&CK cloud matrices.

Cloud incidents need a few special first steps.

1. Take a disk snapshot before you shut down a hacked server, or you lose the evidence.
2. Deactivate a leaked key first instead of deleting it. You can switch it back on if a system breaks, then delete it once the investigation is done.
3. Revoke active sessions, not just passwords.
4. Set up a separate forensics account in advance.

Keep your provider’s support contacts in every playbook. Then run a practice drill twice a year and time how long it takes to contain the problem.

Cloud Governance for AI and Compliance

Rules only work when people know them, and tools enforce them. These last three tips cover AI, compliance, and your team.

23. Set Rules for AI Tools and AI Workloads

AI systems are now a target. In IBM’s 2026 report, more than 20% of organizations said a breach had targeted their AI models or apps. The most common causes weren’t the models themselves, but hacked APIs, apps, or plugins (27%) and cloud misconfigurations around AI workloads (27%).

Give each AI agent its own identity with only the access its task needs. An agent can do anything its credentials allow, and hidden instructions in a file or web page can trick it into misusing that access. This is called prompt injection.

Require a human to approve risky actions, like deleting data or sending money. Log every prompt and tool call.

Publish an approved AI tools list so staff don’t paste cloud data into tools you haven’t reviewed. For more detail, see the OWASP Top 10 for LLM Applications, MITRE ATLAS, and the NIST AI Risk Management Framework.

24. Map Cloud Security Policies to Compliance Rules

Write short security policies that say who can do what in your cloud. Then match each control to the rules you must follow, such as GDPR, HIPAA, PCI DSS, or SOC 2.

The Cloud Security Alliance’s Cloud Controls Matrix saves time here. It maps its controls to frameworks like ISO 27001, PCI, and NIST, so one control can cover several audits.

Watch out for provider reports. You can download them from AWS Artifact, the Microsoft Service Trust Portal, or Google Cloud’s Compliance Reports Manager, but they only prove the provider’s side. Auditors will still ask for proof of your own settings.

Where to track it. AWS Audit Manager, Microsoft Defender for Cloud regulatory compliance, or Google Security Command Center compliance reports.

25. Teach Staff to Recognize Security Risks

Generic phishing training isn’t enough anymore. Google’s H1 2026 Threat Horizons Report found that attackers went after logins across cloud and SaaS platforms using phone scams and token theft, and that a compromised identity was behind 83% of the break ins it studied.

Build real security awareness around these tricks.

• Fake app requests. A pop up asks to “allow access” to your mail or files. Approving it hands cloud access to an attacker, no password needed.
• Device code scams. A message asks you to enter a short code on a real Microsoft or Google page. That code signs the attacker in.
• Help desk calls. Someone poses as an employee and asks IT to reset their MFA. Require a video call or manager check before any reset.

Tailor training for engineers, finance staff, and executives. Tools with cloud access security features, such as a CASB, can also block risky app connections.

Finally, give each of these 25 tips a named owner so none of them fade over time.

Hybrid and Multicloud Security Practices

Most teams don’t run just one cloud. Good hybrid cloud security best practices and multi cloud security best practices use the same 25 tips, applied the same way everywhere, so gaps don’t open between platforms.

• Use one identity system: Connect AWS, Azure, Google Cloud, and your office systems to a single sign in provider. One set of MFA rules and one offboarding switch then covers everything.
• Protect the sync server: In hybrid setups, a tool like Microsoft Entra Connect copies office accounts to the cloud. Microsoft says this server must be treated as a Tier 0 system, its highest protection level, and hardened as a control plane asset. If attackers take it over, they can reach both sides.
• Secure the link between office and cloud: Private connections like AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect still need monitoring. Check whether traffic on the link is encrypted, and add encryption if it isn’t.
• Use shared tags and one dashboard: Apply the same owner and environment tags on every platform, and pull alerts into one place. The same security measures on every cloud build a resilient cloud, since no single platform becomes the weak spot.

No single tool gives you comprehensive security across every provider. Consistent rules and clear owners matter more than the number of products you run.

Native Cloud Computing Security Tools by Provider

Each provider has its own tools for cloud computing security. Use this table to find the right one for each task in this guide.

Note on AWS names. AWS released a new version of Security Hub, and the older version is now called AWS Security Hub CSPM, which still handles posture checks. The new Security Hub became generally available in December 2025 and combines findings from GuardDuty, Inspector, and Security Hub CSPM to rank the biggest risks.

Some of these tools cost extra or need a paid tier, so check pricing before you turn everything on.

Cloud Security Checklist

Use this cloud security best practices checklist to track your progress. Each line matches a tip above. Tick it only when the answer is a clear yes.

Quick wins (do these this week)

• ☐ Every service we use has a named owner for patching, settings, and backups (Tip 1)
• ☐ All admins sign in with passkeys or security keys (Tip 4)
• ☐ Root and global admin accounts have no access keys and trigger an alert when used (Tip 6)
• ☐ No passwords or keys live in our code, and secret scanning is on (Tip 11)
• ☐ Public access is blocked for storage across every account (Tip 13)
• ☐ Logging is on in every account and stored somewhere attackers can’t delete it (Tip 19)
• ☐ Staff know how to spot fake app requests, device code scams, and fake help desk calls (Tip 25)

Foundational (finish this quarter)

• ☐ Every cloud account, subscription, and project has an owner (Tip 2)
• ☐ New workloads land in a secure landing zone (Tip 3)
• ☐ No user or app has more access than its job needs (Tip 5)
• ☐ Access is reviewed every quarter, and leavers lose access the same day (Tip 8)
• ☐ We know where all sensitive data lives, including copies and backups (Tip 9)
• ☐ Sensitive data is encrypted with keys we control (Tip 10)
• ☐ Backups are locked, stored in a separate account, and tested twice a year (Tip 12)
• ☐ Production is separated from test systems, and outbound traffic is filtered (Tip 14)
• ☐ Public apps sit behind a web application firewall (Tip 15)
• ☐ Workload images are scanned and rebuilt on a schedule (Tip 16)
• ☐ Flaws that attackers already use get patched first (Tip 18)
• ☐ Threat detection is on in every region, with cost alerts set (Tip 20)
• ☐ We’ve practiced our incident response plan in the last six months (Tip 22)
• ☐ Each control maps to a compliance rule we must meet (Tip 24)

Advanced (plan for next)

• ☐ Apps and pipelines use short lived credentials instead of saved keys (Tip 7)
• ☐ Security scans run in every build, and outside actions are pinned to a commit ID (Tip 17)
• ☐ Guardrails block risky settings before they’re created (Tip 21)
• ☐ AI agents have their own limited access, and staff use approved AI tools only (Tip 23)

Any unchecked box is a security gap to assign this week. Review the full list every quarter, since new accounts and tools appear all the time.

Turning the List Into a Cloud Security Strategy

Twenty-five tips can feel like a lot. A simple plan turns them into a cloud security strategy your team can actually follow.

This week. Finish the seven quick wins. They take hours, and they block the most common ways attackers get in.

This quarter. Work through the fourteen foundational tips. Give each one an owner and a due date.

Next, plan the four advanced tips once the basics are solid.

Track three numbers at the start and again every month.

1. The share of admins who sign in with passkeys or security keys
2. The number of access keys older than 90 days
3. How long it takes for a new alert to reach a named person

When those numbers move the right way, you know the top cloud security best practices in this guide are working. A secure cloud comes from small habits kept up over time, not from one big project.

FAQ’s