What AWS actually weighs
The review rests on two pillars, and they carry equal weight: technical excellence and business outcomes. Teams pour everything into the first and treat the second as a formality. That imbalance is the most common reason a strong team stalls.
On the technical side, AWS looks past the fact that a workload moved and into how it was built. Expect them to check that your infrastructure is defined as code and rebuilds cleanly, that access is scoped and credentials are short-lived, that data is encrypted and its keys governed, that releases are peer-reviewed and tested automatically, and that each system holds to defined performance targets under load. Have that evidence ready per project as real configuration, pipelines, and documentation you can show on request.
The business side is where depth usually goes missing. A strong business outcome is more than a line saying the client moved to AWS. It is a concrete before and after: what changed for the client once the work shipped, put in terms a business leader would care about. The clearest submissions attach a number to it, a cost that came down, a market the client could enter, hours of manual work removed, a release cadence that sped up. Around the result, AWS wants the process that produced it: how you ran discovery, how you planned the cut-over, how you kept the client live through the change. And they want that pattern across more than one engagement, because a Competency certifies how you work, and one project can be luck.
Read the program before anything else
The most useful hour you can spend comes before any writing: read the Competency program end to end. Most teams skip it and pay for that later.
The program does two things for you. It tells you plainly whether you qualify, which is worth confirming before you sink weeks into an application. And it hands you the exact bar in advance, because the self-assessment questions and the evidence each one needs are laid out in the program itself. Read them early and you can map your existing projects against every requirement, see where you are strong, and find the gaps while you still have time to close them. By the time you write your answers, you are matching real evidence to a standard you already know, which turns the self-assessment from a guessing game into a checklist.
Know who owns what
Two teams carry this, and naming their lanes early keeps the process clean.
Your DevOps engineers own the technical half. They know how the systems are built, they hold the evidence AWS asks for, and they answer the technical questions in the audit. Bring them in from day one. The Alliance side owns the rest: the business case, gathering and writing the outcome narratives, and moving the submission through each stage. When those two run in parallel, technical evidence on one track and business evidence on the other, the whole thing moves.
The AWS Competency team is your most underused resource. A PDM plays a small part here, but the Competency reviewers are open and generous with their time. They will read your draft, tell you where it falls short of the bar, and walk you through how to close the distance before you submit. Reach out early. A gap they flag in a review call is one you fix in an afternoon. The same gap found after submission sends the whole package back for weeks.
Inside the audit
The audit is the part teams dread, and it is calmer than its reputation. It is a conversation about the self-assessment you already completed. When that document is solid, you walk in prepared, because every question traces back to something you have already written.
Bring the right people. Your DevOps engineers, so technical questions get exact answers and, when the auditor asks to see a pipeline or a configuration live, someone can show it on the spot. Your Alliance lead, to steer the business and process discussion. And, when a specific case comes up, someone who knows that engagement well enough to speak to it in detail.
The rest is simple: follow the self-assessment as your guide, answer openly, and stay honest. Auditors probe, and they can tell when an answer is thin. A team that knows its own work and speaks straight about it clears the call cleanly.
It is worth it
A Competency is real work, and it returns more than the badge. The process forces an honest look at how you build and how you serve clients, and most teams come out sharper for it. When the work is good, earning it comes down to preparing well and showing it clearly. We would do it again, and now you have the map.
.avif)
