AWS Consultant: What Does the Partner Badge Actually Prove?

The short answer
  • AWS Advanced Tier Services Partner is a tally: eight accredited individuals, six technical certifications and twenty launched opportunities carrying $10,000 of combined monthly recurring revenue — an average of $500 a customer.
  • One badge in the set involved an auditor. The MSP Specialization is validated by a third-party audit of technical skill and business health; the tiers are validated by counting.
  • Certifications belong to people and lapse after three years, so ask for the badge links of the two engineers who will be named on your statement of work, not the logo on the vendor's site.
  • AWS Service Delivery and AWS Service Ready Specializations are closed to new applications and are deprecated on 1 June 2027, so a badge from either is history rather than a current claim.

Every AWS consultant on your shortlist has a badge. Advanced Tier Services Partner, two or three specialisations, a row of logos above the fold. Somewhere in your evaluation, somebody is going to treat that row as the technical due diligence, because it looks like a certification and it came from AWS rather than from the vendor's marketing team.

Here is the position. The tier tells you how many of the firm's people sat an exam and how much AWS it has sold. Exactly one badge in the usual set involved an auditor looking at how the work is actually run, and it is rarely the one on the homepage. Read what each programme requires and they become genuinely useful — as a first cut, not as evidence.

If you are an NBFC this is not optional reading. The RBI's Managing Risks in Outsourcing Directions, 2025 require you to perform due diligence "to assess the capability of the service provider to comply with obligations in the outsourcing agreement on an ongoing basis". A logo is not an assessment of capability.

What does an AWS consultant's Partner tier actually measure?

To AWS's credit, the requirements are published rather than implied. The Services Partner Tiers page lists them line by line.

Select needs four accredited individuals — two technical, two business — plus two Foundational and two Technical certifications, and three launched opportunities with total monthly recurring revenue of at least $1,500. Advanced needs eight accredited individuals, four Foundational and six Technical certifications of which at least three are Professional or Specialty, and twenty launched opportunities totalling $10,000 MRR. Premier needs twenty accredited individuals, twenty-five Technical certifications with at least ten at Professional or Specialty level, fifty launched opportunities at $50,000 MRR, a partner business plan, an executive business review, sustained attainment over six months, and three programme validations that must include MSP, DevOps or CloudOps. The annual APN fee is $2,500 at every tier.

Do the arithmetic on the Advanced row, because it is the one you will see most often. Twenty launched opportunities carrying $10,000 of combined monthly recurring revenue averages out at $500 a month per customer. That is a real business. It is also not, on the face of it, twenty regulated production accounts. Advanced Tier says this firm has trained eight people and sold AWS twenty times, and it says nothing at all about whether anyone reviewed the twenty accounts afterwards.

The Services Path itself is a registration. AWS defines it as being "for organizations that deliver consulting, professional, managed, and value-added resale services" — a description of what you sell, filled in by you.

Which AWS partner badge involved an audit?

The MSP Specialization. AWS's programme page says it requires "a rigorous third-party audit that assesses your technical skills and business health per enterprise standards". Not a form and not a self-assessment: an auditor, asking to see things. AWS's partner blog has put the cadence at a "Full Audit of all MSP Partners every 36 months", and the controls added in version 4.2 of that checklist covered managing multiple AWS customer accounts, connecting partner shared service accounts and customer offboarding. Those are precisely the three places a vendor-run account goes wrong.

Competencies sit one rung below. Partners "must first complete rigorous technical assessments including reviews of multiple customer success examples aligned to the Specialization they wish to be recognized for", per the specialisations page. Somebody read case studies in a named use case. That is worth more than a count of certified staff and less than an audit.

So if you want a ranking: the MSP audit, then a Competency in a use case that resembles yours, then the tier. Most vendor websites present them the other way round, largest logo first, and the tier is usually the largest logo.

Why is a badge the firm's and a certification the engineer's?

Because the tier counts heads at an organisation on a particular day, and a certification lives with a person who can resign. Eight accredited individuals in March is not eight in October, and the Professional-certified engineers in the tally are not necessarily the ones who will be on your account.

AWS makes this checkable and almost nobody checks it. Individual certifications are issued through Credly, and AWS's digital badge page says the mark "verifies whether your AWS Certification is active or not" and that holders must "recertify every three years". So ask the specific engineers who will be on your account for their badge links. Not the firm's marks. Theirs.

We get asked for this maybe one time in ten, which we think is a mistake, and the first time a prospect asked us we had to go and hunt two of them down. If the answer you get is that resourcing will be confirmed after signature, you have learned something more useful than any tier.

Which badges are on their way out?

Two whole families of them. The same specialisations page states plainly that "AWS Service Delivery and AWS Service Ready Specializations will be deprecated on June 1, 2027. New applications are closed."

A "Service Delivery — Amazon EKS" badge is real and was earned. It also belongs to a programme nobody can enter any more. If a consultant's differentiation on your shortlist rests on one of those, the fair question is what replaces it and whether they have started.

What should you ask an AWS cloud consultant instead?

Five questions. None of them has a logo attached, all of them are answerable in writing before you sign, and the answers tell you more than the whole logo row:

  • How will your engineers get into my account — a role my account owns and yours assumes with an external id, or an IAM user with a long-lived key? The difference, and what the trail shows afterwards, is the whole of the access-model question.
  • On the last day, whose name is on the management account, the organisation trail and the Terraform state bucket? What you should own when they leave is much easier to settle now than then.
  • What exists on day thirty, and can my own engineer approve a production apply? A first month should end with a pipeline you own rather than an assessment.
  • Which of the RBI's outsourcing clauses will you sign, and what is your incident notification commitment in hours? The clauses are in the contract post.
  • Where do backups, logs and monitoring data land, by region and by vendor? Data leaves India in places nobody decided on, and a consultant who has done this in ap-south-1 answers without checking.

What can you send on Monday?

An evidence request. Paste this into the reply to their proposal, before the next call, and let the shape of what comes back do the sorting:

1. Your AWS Partner tier today, and the date it was last renewed.
2. Every AWS Specialization you hold, and the use case each one covers.
3. Do you hold the AWS MSP Specialization? If so, the date of your last
   full third-party audit and the name of the auditing firm.
4. Digital badge links for the two engineers who will be named on our
   statement of work. Not a company certification total.
5. One redacted architecture diagram and one redacted incident report
   from a regulated account, with identifiers removed.
6. The IAM access model you will ask us for, written as a trust policy.

Half an hour to write, and it sorts a shortlist faster than three calls. Item six is the tell. A firm that has done this before sends back a trust policy with an sts:ExternalId condition in it and no argument. A firm that asks for an IAM user with AdministratorAccess attached has just described how it runs every other account it touches, including the ones behind the logos.

When is the tier actually a useful filter?

When you have forty names and an afternoon. The tier is a cheap first cut, and it does remove the one-person reseller: somebody paid the $2,500, kept people certified and closed business repeatedly. Premier is harder still to manufacture, because fifty launched opportunities and three programme validations sustained over six months describes a company with a real bench. If you are migrating a large estate, that bench matters more than anything else here.

And if the work is a lift-and-shift of a stateless application with no regulator anywhere near it, the badge may genuinely be all the diligence the decision needs. The gap opens when the account has to survive an audit, because nothing in the tier requirements mentions log retention, data residency, incident response or who holds the root credentials. Those are the things your auditor asks about, and AWS never claimed the tier covered them.

We are an interested party here, obviously. We answer those same six items in writing when a prospect sends them, and the criteria we would want to be judged on are in our own guide to picking a DevOps company for a fintech, where we rank ourselves first and say so on the page.

The short version

Read the requirements before you weight the badge. A tier is a count of certified staff and closed deals; a Competency is a review of case studies; the MSP Specialization is the only one where an auditor turned up. Rank them in that order, which is backwards from how most websites present them.

Then send the six-item evidence request this week, and read the trust policy that comes back first. Ask the two engineers who will actually be on your account for their badge links, and check the dates. If a vendor treats any of that as an unusual request, that is your finding, and it arrived before you signed anything rather than during your next audit.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.

Why teams pick ReGoBs

We are a DevSecOps company in Kochi, working with fintech, crypto and AI teams across India, the UAE, the US and the UK. Infrastructure we build and run has secured over $3B in transaction volume at 99.9% uptime, for clients including BILLDESK and Coinshift and for teams backed by Y Combinator and Sequoia.

The work is built to survive an audit rather than to describe one: SOC 2 Type II, ISO 27001, PCI DSS and SLSA 3. Our VAPT team holds OSWE certification, has spoken at Defcon, BlackHat and OWASP, and has found critical CVEs in open source software.

We rank ourselves first in our guide to choosing a DevOps company for a fintech — and we say so on that page, in the second paragraph, rather than presenting it as a neutral list. Read the criteria there and hold us to them.

What did the last consultant leave in your account?

We run a free cloud audit on an account somebody else built: who can get in from outside, what the trail actually records, where the Terraform state lives and whose name is on it. No deck, just the findings and what we would fix first.

Book the free audit Cloud Consulting Services: What Should You Own When They Leave?