Best Cloud Security Checklist for VPS and Server Admins

Cloud

If you’re running servers today, your attack surface is bigger than it was even two years ago. Attackers are the same, but with the tremendous increase in cloud infrastructure capabilities comes more security risks.

Cloud security no longer involves a single perimeter around your infrastructure. Now security teams are making decisions in dozens of places at once. Every SSH key, API token, CI/CD pipeline, and now AI agent with server access is a potential entry point. The old model of “harden the perimeter and constantly search out security gaps” is no longer sufficient to cover distributed workloads, automated deployments, and tools that can act on your behalf.

That shift is happening fast. According to Foundry’s 2026 Cloud Computing Study, 74% of IT decision-makers say their organization has accelerated its migration to the cloud over the past year, and 47% say cloud security capabilities are becoming a higher strategic priority precisely because of it.

That doesn’t mean starting over. Most of the cloud security best practices still hold: least privilege, patching, encryption, and backups. But the scope of cloud environments has vastly increased, and a cloud security strategy built today has to account for far more than it did even a couple years ago.

This guide covers the practical steps to combat cyber threats worth taking today, from remote access control to how to scope permissions for an AI agent, to strengthen your cloud security posture management.

TL;DR

Here’s a quick-reference list of the cloud security best practices covered in this guide, organized by category so you can jump straight to what’s relevant.

Category	Checklist items
Identity and access	Enforce least privilege for every user, account, and API key. Rotate SSH keys on a schedule, disable password authentication.
Remote access	Enforce MFA on RDP and admin-level SSH. Restrict access by IP allowlist, gate behind a VPN. Move off default ports.
Patching	Set and stick to a regular patching cadence. Automate updates where safe, track what’s actually running. Don’t neglect dependency and library patching.
Encryption	TLS on every connection carrying sensitive data, not just the main site. Encrypt at rest, manage keys deliberately and rotate them.
Network segmentation	Isolate by function, restrict what’s actually public-facing. Use private networking for internal traffic. Review firewall rules regularly.
DDoS and traffic	Know what your baseline protection actually covers. Monitor traffic patterns, not just uptime. Rate limit exposed endpoints.
Backups and recovery	Follow the 3-2-1 principle. Test restores on a schedule, not just when something breaks. Document your actual disaster recovery plan.
Logging and monitoring	Centralize logs, monitor for anomalies not just errors. Tune alerts so people actually act on them. Set retention based on realistic detection timelines.
AI agents and automation	Scope agent permissions like you would a person’s. Know exactly what each agent can reach. Log and review agent actions before they ship.
Compliance	Know which frameworks actually apply to you. Check data residency requirements before architecting infrastructure. Document controls, not just implement them.
The human factor	Train with realistic examples, not generic awareness content. Have an incident response runbook ready before you need it. Treat offboarding as a security process.

Identity and access management first, network security second

Most breaches don’t start with someone breaking through a firewall. They start with credentials that shouldn’t have worked. A leaked API key, a service account with more access than it needed, a password that never got rotated after an employee left. Getting identity and access management right does more for your security posture than another layer of network defense.

Least privilege access

Start with least privilege. Every user, service account, and API key should have access to exactly what it needs and nothing else. That sounds obvious, but it usually gets ignored, because it’s easier to grant broad cloud access once than to scope it precisely and revisit it later. Audit access control lists periodically, not just when something goes wrong.

SSH key management matters more than most teams treat it. Rotate keys on a schedule, not just when someone leaves. Use a dedicated key per person or service rather than sharing one across a security team. It makes revocation and auditing a lot easier.

Disable password authentication for SSH entirely where you can. Key-based auth alone closes off a huge category of brute-force and credential-stuffing attempts before they’re even a consideration.

None of this replaces network-level controls. Firewalls and segmentation still matter, and we’ll cover that. But identity is how attackers try to first gain access, and it’s the one most often left loose. This is essentially Zero Trust thinking applied at the identity layer, verify every request rather than assuming anything inside your network is automatically safe.

Harden remote access (RDP/SSH)

Remote desktops and SSH access are still the most direct paths into virtual machines, and the most targeted. Strengthening your cloud security against weak sign-in credentials, unencrypted connections, and default port exposure are the most common ways to keep your RDP secure and protect sensitive data. This section covers the controls worth prioritizing

Enforce MFA on remote access

A password alone, even a strong one, isn’t enough for RDP or admin-level SSH access. Multi-factor authentication adds a step that stops most automated credential-stuffing attempts, even if a password does leak.

IP allowlisting

If your team connects from known locations or through a VPN, restrict RDP and SSH access to those IP ranges. This alone removes your cloud data from the pool of targets scanned by bots probing the open internet for exposed ports.

Gate access behind a VPN

Rather than exposing your remote desktop or SSH directly to the internet, put it behind a VPN. Anyone trying to connect needs to authenticate to the VPN first, which adds a layer attackers have to clear before they can even attempt to log in to the cloud service.

Change default ports

Not a security control on its own, but moving RDP and SSH off their default ports (3389 and 22) cuts down significantly on the volume of automated scanning traffic hitting them. Pair it with the threat detection steps above, like enabling multi-factor authentication and incorporating principle of least privilege.

Patch management and update discipline

Unpatched software is one of the most consistent ways servers get compromised. It’s human nature—
patching gets deprioritized until a data breach forces the issue. A known cloud security risk with a public exploit is a far easier entry point than anything requiring custom work from an attacker.

Set a patching cadence

Don’t wait for a security incident to trigger updates. Define a regular cadence, weekly or biweekly for critical patches, monthly for lower-severity ones, and treat vulnerability scanning as a standing task in your cloud workloads, not a reactive one.

Automate where it’s safe

Unattended upgrades for cloud security patches on Linux, or automatic updates for OS-level fixes, reduce the window between a patch being released and it actually being applied. Reserve manual review for major version upgrades or anything else in the software development lifecycle that could break dependencies.

Track what’s actually running

You can’t patch what you don’t know you have. Keep an inventory of installed packages, versions, and dependencies across your cloud services, especially if you’re running multiple environments or a mix of OS versions. Continuous monitoring catches problems while they’re still small, an unexpected login, or a permission change that shouldn’t be there.

Don’t ignore dependency and library patching

OS-level patches get attention, but outdated libraries and packages inside your applications are just as often the actual entry point. Include dependency scanning as part of your regular cloud security routine, not as a separate afterthought.

Encryption at rest and in transit

Data moving between your server and a user, sitting on disk, or passing through your cloud service provider’s infrastructure, is a target either way. Encryption doesn’t stop every attack, but it makes stolen data far less useful to whoever took it.

Encrypt data in transit

TLS should cover every connection in your cloud environment that carries anything sensitive, not just your main web traffic. That includes internal API calls, database connections, and admin interfaces. A service that’s “internal only” today can end up exposed later through a misconfiguration, encrypting it from the start removes that risk entirely.

Encrypt data at rest

Full-disk encryption on your servers, and encryption at the volume level for attached block storage, protects data if a physical disk or storage volume is ever accessed outside of your normal server environment. Kamatera block storage functions as a virtual disk attached to a server, so this is something you configure at the OS or volume level, rather than something that happens automatically.

Manage data encryption keys deliberately

Encryption is only as strong as how you handle the keys. To protect cloud environments, don’t store keys alongside the data they protect, and rotate them on a schedule rather than leaving the same key in place indefinitely.

Don’t treat encryption as a compliance checkbox

It’s easy to enable data encryption once and consider the job done. Revisit cloud security configurations periodically, since secure cloud environments from a few years ago aren’t necessarily secure now.

Network segmentation and private networks

Not every cloud service on your infrastructure needs to talk to every other service, or to the internet. Flat networks make it easy for an attacker who compromises one server to move freely to the rest, and weaken your overall cloud security posture. Segmentation limits how far a single data breach can spread.

Isolate by function

Separate your database tier, application tier, and any admin or management interfaces onto different network segments. For optimal cloud security, a compromised web server shouldn’t have a direct path to your database unless that specific connection is required.

Use private networking for internal traffic

Traffic between your own cloud resources like database connections, internal API calls, or service-to-service communication doesn’t need to touch the public internet. Keeping it on a private network removes an entire category of exposure and cuts down on what’s reachable from outside.

Restrict what’s actually exposed

Only the services that genuinely need public access, typically your web server or load balancer, should have a public-facing interface. Everything else, admin panels, databases, internal tools, should sit behind the private network or a VPN, with cloud security controls enforcing that separation.

Review firewall rules regularly

Segmentation only works if the rules enforcing it stay accurate. Rules added for a one-off task or a testing environment have a way of outliving their purpose. Periodically review what’s actually open on your web application firewall and why. Your cloud security posture depends on it.

DDoS protection and traffic monitoring

A DDoS attack doesn’t need to breach anything to cause damage, it just needs to make your service unavailable. For most teams, the question isn’t whether to have any protection, it’s whether your security policies matches the scale of traffic you could realistically see.

Understand what baseline protection covers

Most cloud providers include some level of network-layer DDoS mitigation by default. That typically covers volumetric attacks but not more targeted application-layer attacks aimed at a specific endpoint. Application-layer attacks are better addressed with access controls and rate limiting at the endpoint itself, not by DDoS mitigation alone.

Monitor traffic patterns, not just uptime

Continuous monitoring tells you when something’s already down. Traffic monitoring can catch the ramp-up before it gets there, unusual spikes, requests from an unexpected geographic spread, or a surge hitting one specific endpoint instead of the site broadly.

Set rate limits on exposed endpoints

Login pages, search functions, and API endpoints are common targets for both DDoS attempts and simpler abuse like credential stuffing. Rate limiting won’t stop a large-scale attack in multi cloud environments, but it closes off a lot of lower-effort abuse before it becomes a bigger problem.

Have a response plan, not just a mitigation tool

Knowing who to contact, what to check first, and what your provider’s escalation path looks like matters as much as the threat detection itself. A plan you’ve never looked at during an incident response may fall apart under pressure.

Backup strategy and disaster recovery

A backup you haven’t tested is a guess, not a safety net. Ransomware, accidental deletion, and hardware failure all end the same way, if your disaster recovery process doesn’t actually work when you need it. Backups are one of the last lines of defense in any cloud security solution.

Follow the 3-2-1 principle

Regular data backups should follow the 3-2-1 rule for security. Keep three copies of your data, on two different types of cloud storage, with one copy off-site or in a separate environment from your production servers. If your only backup lives on the same infrastructure as the data it’s protecting, a single incident can take out both at once.

Test restores, not just backups

Restore testing should be part of your security policies. Taking a backup is the easy part. Actually restoring from it, on a schedule, not just when something breaks, is what tells you whether the backup is usable. A corrupted or incomplete backup only gets discovered at the worst possible time if it’s never been tested.

Automate the backup schedule

Manual backups get skipped. Automate the process with cloud native tools and set alerting for failed backup jobs, so a silent failure doesn’t go unnoticed for weeks, causing major cloud computing fiascos.

Have an actual disaster recovery plan

Backups are one part of recovery, not the whole plan. Know your recovery time objective and recovery point objective for different types of cloud security failures, and document the actual steps for restoring service, not just where the backups live.

Logging, monitoring, and alerting

You can’t respond to what you can’t see. Most cloud security incidents that turn into serious damage weren’t invisible. They were visible in logs nobody was watching, which is exactly the gap cloud security monitoring is meant to close. Consistent visibility here is also a core part of security posture management more broadly, not just incident response.

Centralize your logs

Pulling logs from individual servers after an incident is slow and often incomplete, especially if the affected server itself was compromised. Ship logs to a centralized location in near real time, so you have a record that survives, even if the source system doesn’t.

Monitor for anomalies, not just errors

Error logs catch things that are already broken. Anomaly detection catches things earlier, often before they become an actual incident, like an unfamiliar login location, a spike in failed auth attempts, or a process that shouldn’t be running.

Set alerts that people actually act on

Alerting that fires constantly for low-priority noise trains people to ignore it, including the alert that eventually matters. Tune thresholds so alerts correspond to things worth interrupting someone for, and route them to whoever can actually act on them.

Retain logs long enough to be useful

Some data security incidents aren’t discovered until weeks after they happened. If your log retention window is shorter than that, you lose the ability to investigate root cause. Set retention based on realistic detection timelines, not just storage cost.

Securing AI agents and automated workflows

AI agents and automated tooling now hold credentials, make changes, and touch production systems the way a human admin used to, often with fewer access controls. This is a newer category of risk, and most cloud security checklists haven’t caught up to it yet.

Limit agent permissions

An AI agent with shell access, an API key, or deployment credentials should get exactly what it needs to do its job, nothing more. Don’t hand an agent root access or an all-access API key because it’s faster to set up. The same principle of least privilege from section 1 applies here.

Know what agents can actually reach

Map out what each agent or automated workflow has access to, databases, production servers, billing, deployment pipelines, and confirm that access matches what it’s actually supposed to do. Scope tends to expand over time as an agent gets used for more cloud computing tasks. Each expansion is a data protection question as much as an access controls question.

Log and review agent actions

Treat automated actions the same way you’d treat admin actions, with an audit trail. If an agent makes an unattended change to configuration, code, or infrastructure, you should be able to see what changed, when, and why.

Review agent-generated changes before they ship

Code or configuration changes coming from an AI agent should go through the same review process as a first-time contributor’s pull request, not get merged automatically because it came from a tool rather than a person. Automation speeds up the work, but don’t remove the review step.

A hypothetical example

Say a coding agent is given access to a deployment pipeline to speed up routine releases, and along the way it’s granted broader permissions, like access to environment variables containing database credentials. Months later, that same agent is used for an unrelated task, a script that unintentionally logs environment variables for debugging. Nobody reviews the log output before it’s shipped to a less secure logging destination. That’s an expansion of the attack surface that nobody noticed, and it’s exactly what cloud security solutions like scoped access and a mandatory review step are meant to catch, at two separate points.

Compliance and data residency

Compliance monitoring isn’t a separate track from security; it’s often the same controls with a different audience. But regulatory requirements do add specific obligations that general best practices don’t automatically cover.

Know what applies to you

Whether it’s GDPR, HIPAA, SOC 2 compliance, or PCI DSS, your cloud compliance frameworks depend on your industry, your customers’ locations, and what kind of data you handle. Not every business needs to meet every framework, but assuming none apply without checking will impact your cloud computing security.

Understand data residency requirements

Some regulations require that certain cloud data physically stay within specific geographic or jurisdictional boundaries. This affects where you host, where backups live, and where any disaster recovery infrastructure sits. Check this before you architect your infrastructure, not after.

Document your controls, not just implement them

Having the right security controls in place isn’t the same as being able to demonstrate them during an audit. Keep records of what’s configured, when it was last reviewed, and who’s responsible for it, this is usually the part that catches teams off guard, not the technical controls themselves.

Cloud compliance requirements shift

Regulations get updated, and what qualified as compliant last year isn’t guaranteed to still qualify. Any specific regulatory claims in this section should be checked against the current text of the relevant cloud computing regulation before publishing.

The human factor: training and process

Most cloud security failures aren’t a technical gap, they’re a person doing something reasonable that turned out to be the wrong move. A convincing phishing email, a credential reused across systems, an offboarded employee whose access never actually got revoked. Regular security training reduces risky employee behaviors.

Train for recognition, not just awareness

Generic “don’t click suspicious links” training doesn’t hold up against a well-crafted phishing attempt. Training that uses realistic examples, specific to the kinds of requests your team actually gets, sticks better than a once-a-year compliance video. Your employee training should also include phishing detection and password hygiene.

Have an incident response runbook

If something goes wrong, the time spent figuring out which network security groups
does what is time your attacker gets to keep moving. Document who gets notified, what gets isolated first, and who has authority to make decisions, before you need it, not during.

Treat offboarding as a security process

Revoking access to your virtual private clouds when someone leaves a team or the company needs to be immediate and complete, not a task that happens whenever someone remembers. That includes SSH keys, API tokens, shared credentials, and any third-party tools they had access to, not just their main account.

Make it easy to report mistakes

Someone who clicked a phishing link and is afraid to say so costs you more time than someone who reports it immediately. A process that punishes disclosure teaches people to hide problems instead of surfacing them.

Security tools in the Kamatera Marketplace

You don’t have to build all of this from scratch. The Kamatera marketplace includes several apps that map directly onto the practices above. They’re worth knowing about, if you’d rather deploy a tool than configure something from the ground up.

Network and perimeter security

OPNsense and FortiGate are firewall platforms, for dedicated data security beyond what’s configured at the server level, ties back to the segmentation and traffic monitoring practices covered earlier.

Remote access and VPN

OpenVPN, UTunnel VPN, and NetBird are all available for gating remote access behind a VPN rather than exposing RDP or SSH directly, the same principle covered in the remote access hardening section. NetBird in particular is worth a look, if you want private networking without the overhead of managing your own VPN infrastructure.

Credential management

Passbolt and Vaultwarden are self-hosted password managers. Storing credentials in a dedicated, self-hosted manager rather than scattered across spreadsheets or shared documents is one of the simpler upgrades a team can make to its identity and access practices.

API security

Kong is available as an API gateway, relevant if you’re running multiple services with APIs that need centralized authentication, rate limiting, or traffic control, especially relevant now that AI agents and automated tools are making API calls of their own.

Conclusion

None of this is about achieving some final, permanent state of being secure. Cloud security today is closer to an ongoing practice than a checklist you complete once. New tools get added, teams change, or AI agents pick up more of the routine work.

A strong cloud security strategy isn’t built on any single control. It’s least privilege and MFA working alongside encryption and monitoring, backups, and a process for reviewing what AI agents and automated tools can reach. None of these individually would stop everything, but together they close most of the paths an attacker or a mistake could take.

It’s also worth remembering the shared responsibility model here: your cloud provider secures the infrastructure underneath you, but what you configure, who has access, how your data is encrypted, is still on you. Knowing where that line sits matters as much as any individual control.

The cloud security best practices in this guide aren’t exotic. Most of them are fundamentals applied consistently rather than novel techniques. If you take one thing from these cloud security tips, let it be this: revisit your setup regularly, not just when something forces you to.