In short
- A case study works for customers, sellers and reviews at once
- Plan the numbers before the project ends
- Most delays come from approvals, not from writing
Why case studies decide more than you think
A published AWS case study does three jobs at once. It shows customers you deliver, it gives AWS sellers something to forward, and it is proof for AWS Specialization reviews. Most partners treat it as a marketing extra. It is closer to infrastructure.
AWS names three audiences for a case study: its sellers, customers, and the teams that validate programs. Sellers use case studies to match partners to opportunities, and AWS warns that vague ones "can result in missed co-sell introductions."[1] Case studies are also a required input for AWS Specializations.[1]
Who reviews it
More people read a partner case study than the partner expects, and each one reads it for a different reason.
- You get written consent from the customer first. When you give AWS a case study, the AWS Partner terms make you responsible for having the right to share it.[4]
- You create it in AWS Partner Central, under Case studies. You can write it there, upload a document or import a page you already published.[1]
- AWS checks it automatically against its marketing rules, usually within minutes. If it fails, the status changes to Action required, with what to fix.[2]
- A go-to-market case study gets a light policy check and can be published on AWS sites. One attached to a Specialization application gets a deeper review by the AWS validation team or an auditor.[3][6]
- You publish it on your own site too. For Specializations, AWS asks for public case studies published by the partner, naming the customer, the challenge, how AWS was used and the outcome.[6]
My rule
Plan the proof before the project ends. Asking a customer for numbers six months later rarely works.
What gets a case study sent back
Most case studies come back for the same few reasons. They are about wording AWS does not accept, not about the story.[2]
- A vague challenge or outcome. Name the problem and give a number the customer stands behind.
- Claims you cannot back up: best, first, only, leader, number one. They pass only when they state a fact or a measured result.
- Relationship words AWS rejects: partnership, strategic alliance, jointly, teamed with. Write AWS Partner, or that you worked with AWS.
- Naming: Amazon Web Services (AWS) in full the first time, never Amazon alone, on AWS rather than in AWS, and full service names such as AWS Lambda.
- Fear words in security stories, such as breach, attack, exploit or hacker.
- Anything that suggests AWS endorses you, personal data beyond a quote's name, title and company, or other cloud providers by name.
A timeline that works
| Step | Who | Typical time |
|---|---|---|
| Customer signs the AWS Marketing Authorization Form | You and the customer | [ Weeks ] |
| Draft and numbers | You, with my help | [ Weeks ] |
| Customer approval | The customer | [ Weeks ] |
| AWS review | AWS | [ Depends on AWS: minutes for the automated check, longer for a Specialization review ] |
Checklist
- Customer consent to be named, in writing
- Two numbers the customer will stand behind
- The AWS services used, named correctly
- A quote from the customer, approved
- The AWS team that supported the deal, informed
Sources
- AWS Partner Central documentation: Create a case study
- AWS Partner Central documentation: Case study content requirements
- AWS What's New, October 2026: AWS Partner Central Program Navigator
- AWS Partner Network Terms and Conditions
- AWS Trademark Guidelines
- AWS Specialization validation checklist: Small and Medium Business, consulting