Skip to content

AWS Updated 2026-07-04

How to evaluate an AWS cloud management company: 12 questions that expose the pretenders

Choosing an AWS cloud management company is hard because every website says the same things. These 12 questions separate firms that run production from firms that sell dashboards.

Every AWS cloud management company’s website promises monitoring, security, and cost optimization, which makes websites useless for telling them apart. The difference shows up under questioning: firms that actually run production have specific, sometimes uncomfortable answers about access, incidents, and what went wrong last quarter; pretenders answer everything with tooling names and certifications. Ask the twelve questions below, in a live conversation, and the field sorts itself quickly.

What you are deciding

You are choosing who gets privileged access to the systems your revenue runs on, and who answers when they break at night. That is closer to hiring a senior employee than buying software, and it deserves the same scrutiny: evidence over claims, references over logos, and specifics over adjectives.

The evaluation has three layers. Competence — can they actually operate AWS at your scale? Fit — does their engagement model match your size, stack, and hours? Safety — if the relationship fails, can you leave whole? Each question below probes one of those layers, and the pattern of answers matters more than any single one.

What to check first

Before the meeting, do fifteen minutes of homework so their answers have something to land against:

  1. Know your own environment’s shape — number of accounts, main services, roughly what fires alarms today. Vague buyers get vague scopes.
  2. Check their AWS Partner status on the AWS Partner directory — not because badges prove skill, but because claiming a tier they do not hold is disqualifying.
  3. Read one of their technical articles or runbooks if public. A company that operates infrastructure produces operational writing; one that markets produces listicles.
  4. Decide your non-negotiables in advance — for most buyers: no shared credentials, no provider-owned root, defined incident response times, clean exit terms.

How to verify

The twelve questions, and what a real answer sounds like:

  1. “Walk me through your last significant incident on a client account.” Real operators tell a specific story with a timeline and a lesson. Pretenders say incidents are rare because of their proactive approach.
  2. “What access will you request in our account, exactly?” The right answer names a mechanism — a cross-account IAM role or IAM Identity Center permission sets, scoped and revocable — not “admin credentials”.
  3. “Who is paged at 03:00 and what may they do without asking us?” You want a named rotation and a written boundary, not “our team monitors around the clock”.
  4. “Show me a sample monthly report from a real client, redacted.” If the report is a screenshot of a dashboard, that is the service.
  5. “What is your response target by severity, and what happens when you miss it?” Targets without consequences are marketing.
  6. “How do you handle patching, and what broke the last time a patch went wrong?” Everyone who patches at scale has a story.
  7. “What do you not do?” Real firms decline work — application code, compliance certification, 24/7 for a two-person shop. “We do everything” means they have done nothing deeply.
  8. “How do we leave?” Listen for: your account, your infrastructure-as-code, documented handover, no proprietary lock-in tooling that leaves with them.
  9. “What is in your first 30 days?” A credible onboarding names concrete deliverables: alarm baseline, IAM review, backup verification, CloudTrail confirmation — comparable to the CloudTrail and GuardDuty baseline and the CloudWatch alarm baseline.
  10. “How is your fee structured, and what makes it go up?” Percentage-of-AWS-spend pricing rewards your waste. Flat or tiered pricing tied to scope keeps incentives straight.
  11. “Which AWS services would you tell us to stop using?” Operators have opinions formed by pain. The AWS support tiers themselves are part of this conversation — a good firm will tell you when Business support (https://aws.amazon.com/premiumsupport/) is worth adding under your account rather than reselling it opaquely.
  12. “Can we speak to a client you have had for more than two years, and one who left?” The second half of that question is where the pretenders go quiet.

You can also verify claims technically once shortlisted: ask them to review your account read-only and present findings. Their findings quality is a work sample.

# Grant a candidate read-only review access the safe way:
# a dedicated role they assume, which you delete afterward.
aws iam create-role --role-name candidate-review \
  --assume-role-policy-document file://trust-policy.json
aws iam attach-role-policy --role-name candidate-review \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

# When the evaluation ends:
aws iam detach-role-policy --role-name candidate-review \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
aws iam delete-role --role-name candidate-review

Every action they take during the review is visible in CloudTrail > Event history — which is itself a test of whether you have CloudTrail on.

The approach

  1. Shortlist on evidence, not size. Three candidates is plenty. Public post-mortems, operational blog posts, and named references beat headcount and logo walls.
  2. Run the twelve questions in a live call. Written RFP answers are polished by salespeople; live answers come from whoever will actually do the work — insist that person attends.
  3. Commission a paid read-only review as the bake-off. A short, paid discovery on your real account shows you their actual working quality and gives you a findings document you keep either way.
  4. Negotiate the responsibility table before price. Who acts, who approves, who is informed — for incidents, patching, backups, cost, security, deployments. Price a defined scope, never a vibe.
  5. Start with a defined first quarter. Concrete deliverables, then a review gate. Good firms welcome this; it is their chance to prove out.

When this is the wrong move

If your AWS footprint is trivial, a full evaluation process is overkill — a one-time hardening engagement solves it. If your real problem is application quality (the app crashes under load regardless of infrastructure), an operations firm will document your outages beautifully without preventing them. And if your organization cannot name an internal owner for the relationship, fix that first; an unmanaged vendor drifts exactly like an unmanaged account.

Common mistakes

  • Weighting certifications over incident stories. Certifications prove studying; operations proves itself at 03:00.
  • Letting the provider define the scope alone. Their template optimizes for their margins, not your risks.
  • Skipping the leaver reference. How an engagement ended tells you more than how one is going.
  • Choosing on price for a service whose value is what does not happen. The cheap firm is cheap somewhere — usually the overnight rotation.

Keeping it under control

  • Re-run the paid-review exercise annually as a quality audit of your incumbent.
  • Keep the responsibility table as a living document, reviewed at each renewal.
  • Watch their CloudTrail activity quarterly; access scope creep is silent.
  • Track their response times against the contract yourself — do not rely on their reporting alone.

The firms worth hiring survive all twelve questions comfortably, because the answers are just descriptions of their normal week. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.