AWS for MSPs: Managing Amazon Web Services for your clients

According to the 2026 Kaseya State of the MSP Report, cloud and hosting services rank among the top revenue sources for 34% of MSPs. Amazon Web Services is the dominant platform underpinning a significant share of that workload.

Managing AWS for clients is different from managing it internally. You are accountable for environments you do not fully control, billing structures that require ongoing attention to avoid cost surprises, and security configurations that shift as clients grow. Without the right approach and tooling, AWS client work can be one of the most operationally demanding services an MSP delivers.

This guide covers what MSPs need to know to manage AWS client environments profitably: cost governance, security configuration, backup strategy, and the operational pitfalls that make AWS harder than it looks. Kaseya’s platform is used by MSPs across more than 170 countries to manage exactly these environments, which gives us a clear picture of where AWS client management succeeds and where it breaks down.

Why MSPs manage AWS environments

Most SMB and mid-market clients who move to cloud infrastructure land on AWS. Some were guided there by a consultant. Others needed a specific application that required it. Many simply defaulted to AWS because of its market presence. Whatever the reason, the result is the same: AWS management is now part of the standard client environment that managed services contracts must account for.

Three drivers make it a growing service line.

Application hosting. Clients run line-of-business applications, web servers, databases, and development environments on EC2 instances and managed services like RDS and Lambda. Managing these is as operationally necessary as managing on-premises servers.

Storage and backup. Clients store data in S3 buckets, use EBS volumes attached to compute instances, and increasingly rely on AWS as part of their backup architecture. Knowing what is and is not protected, and what the recovery path looks like, is a core MSP responsibility.

Compliance requirements. Regulated clients in healthcare, finance, and government often have workloads on AWS that must meet the same standards as on-premises infrastructure. HIPAA, PCI DSS, and CMMC all apply to AWS-hosted environments when those environments handle in-scope data.

A typical MSP managing 20 to 50 clients will find AWS environments present in a majority of those accounts within two to three years of today’s adoption trajectory. Scoping that into your service agreements now, before a client asks why their S3 bucket was exposed, is the right time.

Understanding the AWS shared responsibility model

The most consequential concept in AWS management is the shared responsibility model. The most common mistake MSPs make is misrepresenting it to clients, or not representing it at all.

AWS is responsible for the security of the cloud: the physical infrastructure, the hypervisor, the networking fabric, and the managed service infrastructure. The customer, and their MSP, is responsible for security in the cloud. That covers operating system patches, network configuration (security groups, NACLs, VPC design), identity and access management, data encryption, and application-level security.

The practical implications are straightforward:

• An EC2 instance running an unpatched operating system is the client’s problem, not AWS’s.
• An S3 bucket misconfigured for public access is the client’s problem.
• IAM roles with excessive permissions are the client’s problem.
• Application vulnerabilities running on AWS infrastructure are the client’s problem.

MSPs who manage AWS environments must patch operating systems on EC2 instances just as they would patch on-premises servers. VSA supports OS and third-party patching for Windows and Linux instances, including EC2 instances where the VSA agent is deployed, using the same policy-driven automation used for on-premises endpoints.

This matters in contract terms too. If your managed services agreement does not explicitly define who owns OS patching and IAM governance for AWS-hosted workloads, you have a liability gap. Document it clearly in IT Glue and align your SLA language before an incident forces the conversation.

AWS cost management: where MSPs lose margin

AWS billing is complex. Without active governance, it is expensive. The most common cost problems in MSP-managed AWS environments come down to four categories.

Right-sizing failures. Clients over-provision EC2 instances during initial deployment and never scale down. A client running a t3.xlarge for a workload that needs a t3.medium is paying roughly double the necessary compute cost. Regular right-sizing reviews, supported by AWS Cost Explorer and CloudWatch metrics, surface these opportunities before they erode margin.

Reserved Instance and Savings Plan underuse. AWS offers discounts of up to 72% for Reserved Instances and Savings Plans compared to on-demand pricing. MSPs managing AWS environments should identify which workloads are stable enough to commit to reserved pricing, then either purchase reservations on the client’s behalf or advise them to do so as part of a formal quarterly review.

Unattached resources. Clients frequently leave EBS volumes, Elastic IPs, and load balancers running after the associated resources are deleted. These have no operational value but keep accruing costs. A monthly cost hygiene review should include checks for orphaned resources. It takes under an hour and often uncovers hundreds of dollars in monthly waste.

Egress costs. Data transfer out of AWS is billed at rates that catch clients off guard. Applications with high outbound traffic, backup systems transferring data out to other destinations, and CDN-adjacent workloads can generate egress costs that exceed compute costs. Know the egress profile of each client’s environment before they get the bill.

The MSP opportunity here is real. Treating AWS cost management as a proactive advisory service creates genuine client value and supports the commercial conversation about expanding managed services scope. An MSP who spots $500 a month in avoidable AWS spend becomes a trusted advisor. One who misses it becomes the person who let the client waste money.

Security configuration in AWS client environments

AWS provides strong security capabilities, but they must be correctly configured. The most common security gaps in MSP-managed AWS environments follow a predictable pattern.

IAM over-permissioning. The principle of least privilege is harder to maintain in AWS than in a traditional directory environment because IAM roles, policies, and permission boundaries are more complex to audit. Users and service roles with Administrator access when they need only specific service permissions are a routine finding. Regular IAM access reviews and AWS IAM Access Analyzer surface these gaps before they become breach vectors.

Public S3 buckets. S3 buckets default to private, but configuration changes or infrastructure-as-code templates can inadvertently expose buckets publicly. AWS provides bucket-level and account-level public access blocks. Enabling these at the account level prevents accidental exposure.

Missing encryption at rest. EBS volumes, S3 buckets, and RDS instances should all have encryption enabled. AWS KMS provides managed key encryption. Enabling default encryption at the account level ensures new resources are encrypted unless explicitly overridden, which is a sensible baseline for any client environment handling business data.

Permissive security groups. Security groups that allow unrestricted inbound access (0.0.0.0/0) on ports 22 (SSH) or 3389 (RDP) expose instances directly to the internet. These are identified in almost every AWS security assessment and are straightforward to remediate. They should be closed as a first-day baseline on any new client engagement.

CloudTrail not enabled. AWS CloudTrail is the audit log for AWS API activity. Without it, incident investigation is severely limited. CloudTrail should be enabled in all regions, with logs stored in a separate, restricted S3 bucket. This is a non-negotiable baseline for any environment where your MSP is accountable for security.

Backup and recovery on AWS

The shared responsibility model means AWS does not back up most resources by default. EC2 instances, EBS volumes, and RDS databases all require explicit backup configuration.

AWS Backup is AWS’s native backup orchestration service, supporting EC2, EBS, RDS, DynamoDB, EFS, and other services. It provides centralized policy management, cross-region and cross-account copy, and backup compliance reporting. For MSPs managing multiple client AWS environments, the cross-account management capability (available through AWS Organizations) allows backup policies to be managed across client accounts from a central console.

What AWS Backup does not cover: S3 data (protected through versioning and replication rather than traditional backup), SaaS applications running on AWS infrastructure, and application-consistent backup for complex multi-tier applications. Datto BCDR can complement AWS Backup for workloads where image-level recovery capability or faster RTO is required.

Recovery testing. The same principle that applies to on-premises backup applies here: a backup that has not been tested is not a backup. AWS Backup supports restore testing with automated validation. This should be part of the managed service contract for any AWS environment where recovery capability is a contractual commitment. Schedule it, run it, and document the results in IT Glue.

Monitoring AWS environments at scale

AWS CloudWatch provides native monitoring for AWS resources: metrics, logs, alarms, and dashboards. For MSPs managing multiple client AWS environments, the challenge is normalizing AWS monitoring alongside on-premises and other cloud monitoring into a unified operational view.

VSA’s agent-based monitoring covers EC2 instances where the agent is deployed, providing the same endpoint monitoring, alert management, and automation capabilities used for on-premises servers. For infrastructure-level AWS monitoring (service health, billing alerts, CloudTrail events), native AWS tooling or AWS-specific monitoring integrations complement the VSA agent.

The goal is a single operational view. An MSP’s NOC should not need to switch between the VSA console and individual AWS consoles for each client to understand the health of the managed environment. Every context switch adds latency to incident response and creates opportunities for gaps to go unnoticed.

How Kaseya supports AWS client management

Datto RMM / VSA handles OS patching, monitoring, and automation for servers running Windows or Linux. Deploy once, manage alongside on-premises endpoints from the same console.

Datto BCDR complements AWS Backup for workloads requiring image-level recovery, instant virtualization, or faster RTO than native AWS restore provides.

IT Glue stores documentation for client AWS environments: VPC architecture, IAM structure, security group configurations, disaster recovery runbooks, and access credentials, with per-client isolation and controlled access.

Compliance Manager GRC tracks control implementation and generates compliance evidence for clients with regulated AWS workloads (HIPAA, PCI DSS, CMMC), across both on-premises and cloud environments.

Kaseya Intelligence and AWS: autonomous cloud operations

Managing AWS environments means dealing with constant change: new instances, scaling events, configuration drift, security findings from AWS Security Hub, and backup jobs that need validating across regions. The manual overhead of staying on top of that at scale is significant.

Kaseya Intelligence, the AI engine powering Kaseya 365, automates the response layer. Rather than alerting a technician to a finding and waiting for action, it executes: patching, isolating, verifying backup completeness, and validating the outcome. For MSPs managing AWS environments across multiple clients, that execution loop is what prevents alert fatigue from becoming a security gap.

Explore Kaseya Intelligence