Cloud Acceptable Use Policies: What Providers Expect From Account Holders
What cloud acceptable use policies prohibit on AWS, DigitalOcean, Amazon SES, and other providers, the extra rules for email sending, how abuse enforcement works, and how to keep an account compliant.
Every cloud account comes with two documents most people never read: the terms of service, which set the commercial relationship, and the acceptable use policy, which sets what you may and may not do with the resources. The acceptable use policy is the one that gets accounts suspended. It applies to AWS, DigitalOcean, Amazon SES, and every other provider in slightly different wording, and it applies whether you opened the account yourself or took it over from someone else. This guide explains what these policies typically prohibit, what email services expect in particular, how enforcement works, and how to run an account that never triggers it.
What an acceptable use policy is
An acceptable use policy, often shortened to AUP, is the provider’s list of prohibited activities and the standards of behaviour it expects from everyone using its network. AWS publishes a single AUP that covers every AWS service, including Amazon SES, alongside service specific terms. DigitalOcean publishes an acceptable use policy next to its terms of service and adds product policies such as its SMTP policy. Smaller providers fold the same content into their terms. Whatever the format, the policy is a condition of the account: violating it allows the provider to suspend or terminate service, usually without a refund, and the policy is written so the provider decides what counts as a violation.
The reason the policies exist is that a cloud provider’s IP addresses, network, and reputation are shared among all its customers. One customer sending spam or hosting malware gets the provider’s address ranges blocklisted and its abuse desk flooded, so providers act quickly and broadly to protect the platform.
What providers commonly prohibit
The wording varies but the categories are consistent across AWS, DigitalOcean, Google Cloud, Azure, Hetzner, Vultr, and the rest. Most policies also prohibit helping someone else do any of these things, and most reserve the right to act on activity that harms the provider even if it is not explicitly listed.
| Category | Typical examples | Why providers care |
|---|---|---|
| Illegal content and activity | Content that violates law in the provider’s or the customer’s jurisdiction, fraud, sale of illegal goods | Legal liability for the provider |
| Security violations | Malware hosting, phishing pages, credential theft, unauthorised access to other systems, port scanning of networks you do not own | Harm to third parties and to other customers |
| Network abuse | Denial of service attacks, traffic flooding, spoofed packets, open relays and open resolvers | Damage to the shared network and address reputation |
| Unsolicited messaging | Bulk email or messages without consent, forged headers, harvested address lists | Blocklisting of provider address ranges |
| Intellectual property | Distributing copyrighted material without licence, trademark misuse, counterfeit goods | Takedown obligations and legal exposure |
| Resource abuse | Cryptocurrency mining on free tiers or promotional credits, deliberate over consumption, abusive automated account creation | Cost to the provider and unfair use of shared capacity |
| Harmful and abusive content | Harassment, threats, content that exploits minors, incitement to violence | Safety and legal obligations |
| Deceptive practices | Impersonating the provider or others, misrepresenting who controls an account, providing false registration details | Trust and fraud prevention |
Two of these catch honest teams by surprise. Security testing against systems you do not own, even a harmless scan, is treated as a violation; run scans only against your own resources and follow the provider’s penetration testing rules where it publishes them. And mining on trial or credit funded accounts is explicitly banned by several providers, whose trial terms are set by the provider and subject to change.
What email services expect
Email has its own rules layered on top of the AUP because it is the activity most likely to damage a provider’s reputation. Amazon SES starts every account in a sandbox that can only send to verified addresses, and grants production access after a review of the intended use. Once in production, SES monitors bounce and complaint rates and places an account under review or pauses sending when they stay above thresholds it publishes. It also requires that recipients have agreed to receive mail and that every message carries a working way to opt out.
DigitalOcean’s SMTP policy blocks outbound port 25 on new accounts by default and directs customers to a dedicated email service such as SES or a transactional provider for application mail. Other VPS providers apply similar restrictions on new accounts. The right response is to send through a service built for it, keep lists consent based, and comply with anti spam law such as CAN-SPAM in the United States and the consent requirements of GDPR and CASL, rather than to look for a network that does not check.
The Cloud Library article on port 25 and cloud email sending explains the technical side of these restrictions.
How enforcement works
Providers learn about violations from three sources: automated detection of patterns such as outbound scanning or spam traffic, abuse reports sent to the provider’s abuse contact by other networks and blocklist operators, and legal notices such as copyright complaints. What happens next depends on severity. A single abuse report about a compromised server usually produces an email asking you to fix the problem within a stated period. Clear malicious activity, phishing, or repeated reports can lead to immediate suspension of the resource or the whole account, with termination for serious or repeated cases.
Treat every abuse notice as urgent. Read it fully, fix the cause, reply through the channel the notice specifies with what you found and what you changed, and keep the record. Providers are far more lenient with an account that responds within hours than with one that stays silent, and silence is often what turns a warning into a suspension.
Running an account that stays compliant
- Read the AUP and the service specific terms for each provider you use, and reread them when the provider announces changes.
- Keep servers patched and firewalled, because a compromised server sends spam and scans networks under your name. See securing a VPS for the basics.
- Monitor outbound traffic and email volume so unusual activity is noticed by you before the abuse desk notices it.
- Keep the account’s contact email, billing details, and registration information accurate and monitored so notices reach someone who can act.
- Send email only to people who asked for it, honour unsubscribes promptly, and watch bounce and complaint rates.
- Run security tests only against your own resources and within the provider’s published rules.
- Use trial and promotional credits for the purposes the provider allows, and check the terms before running anything heavy on them.
- When you take over an account, review what is already running on it, because you inherit responsibility for its activity from the day access transfers.
Where to go next
The policies described here apply to every account in the marketplace. The product pages for AWS accounts, DigitalOcean accounts, and Amazon SES accounts describe each variant by its label, and each remains subject to the provider’s terms and acceptable use policy after purchase.
For SES specifically, Amazon SES explained covers the sandbox, production access, and quotas, and email deliverability basics covers reputation, warm up, and bounces. The Cloud Library hub lists every security guide.