Skip to content

AWS Updated 2026-10-22

What an AWS managed services provider actually does (and what it should not touch)

Use this to judge an AWS managed services provider before you sign. It explains which daily jobs a provider should run for you, such as monitoring, patching and backups, and which decisions should stay with your team.

If you are comparing AWS managed services providers, or wondering whether you need one, it helps to know what the job actually covers. A provider of this kind runs the daily operation of your AWS account for you. That means watching the environment around the clock, answering incidents, patching operating systems, checking that backups restore, keeping IAM (Identity and Access Management, the system that decides who may do what in the account) tidy, and reviewing the bill each month. Your application code, your product roadmap and the account’s root login should stay with you. If a proposal blurs those lines, treat it as a reason to keep looking.

What you are deciding

The phrase “managed services” covers everything from a reseller who marks up your AWS bill and answers email during business hours to a team that carries a pager for your production environment. Before you compare providers, decide which layer you are actually buying.

There are three distinct layers, and providers routinely sell one while implying another:

  • Billing and account administration — consolidated billing, Reserved Instance purchasing, support-plan resale. Cheap, low value, often mistaken for management.
  • Infrastructure operations — the real thing: monitoring with a human response path, incident ownership, OS and dependency patching, backup verification, IAM reviews, cost reviews. This is what “managed” should mean.
  • Application operations — deploying your code, managing your CI/CD pipeline, sometimes writing infrastructure-as-code for new features. Legitimate, but a separate engagement with separate access requirements.

The boundary questions matter more than the feature list. Who holds root on the account? Who can create IAM users? Who gets paged at 03:00, and what are they allowed to do without asking you? A good provider has crisp answers; a pretender talks about tooling.

What to check first

Before evaluating anyone, establish what your account looks like today, because the gap between current state and managed state is what you are paying to close:

  1. Do alarms exist, and does a human see them? An account with no CloudWatch alarms, or alarms feeding an unread inbox, has no operations today — whatever the org chart says.
  2. Who has admin? List IAM users and roles with AdministratorAccess. If the answer includes ex-employees or shared credentials, IAM cleanup is part of any honest first engagement.
  3. When did anyone last restore a backup? Snapshots existing is not the same as restores working.
  4. Is CloudTrail on in every region? If not, nobody can audit what a provider does later.
  5. Who owns the root email and MFA device? That must be you, before and after signing.

How to verify

Run these read-only checks against your own account before any provider does:

# Who am I, and which account is this?
aws sts get-caller-identity

# Alarm inventory — is anything actually watched?
aws cloudwatch describe-alarms \
  --query 'MetricAlarms[].[AlarmName,StateValue,AlarmActions[0]]' \
  --output table

# CloudTrail: is there a multi-region trail, and is it logging?
aws cloudtrail describe-trails --query 'trailList[].[Name,IsMultiRegionTrail]'
aws cloudtrail get-trail-status --name <trail-name>

# Who holds admin?
aws iam list-entities-for-policy \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

In the console, check CloudWatch > Alarms for anything in INSUFFICIENT_DATA since creation (a sign nobody ever tuned them) and IAM > Users for access keys older than a year. The IAM documentation at https://docs.aws.amazon.com/iam/ describes what healthy credential hygiene looks like if you want the reference point.

The approach

  1. Write the scope down as a responsibility table. For each of monitoring, incident response, patching, backups, cost, security, deployments, and DNS: who acts, who is informed, who approves. If a provider resists putting this on paper, the ambiguity is the product.
  2. Insist on delegated access, never shared credentials. The provider works through a dedicated cross-account IAM role or IAM Identity Center assignment that you can revoke in one action. Root stays with you. The same least-privilege logic applies inside the account — see IAM instance profiles done right for how that thinking extends to workloads.
  3. Make monitoring the first deliverable. A provider who cannot show you the alarm set they will deploy in week one is selling a dashboard, not operations. A concrete baseline looks like the CloudWatch alarm set a production SaaS needs.
  4. Agree on the incident path before the first incident. Severity definitions, response targets by severity, and who communicates with your customers. Response targets differ between business-hours and 24/7 tiers — get the tier you are buying in writing.
  5. Set the cost cadence. A monthly review with concrete actions (rightsizing, commitment coverage, orphaned resources) is the norm. The provider’s fee structure should not grow when your AWS bill grows through waste — percentage-of-spend pricing points the incentive the wrong way.

When this is the wrong move

If your entire footprint is one EC2 instance and an S3 bucket, a managed services contract is overhead — a one-time hardening engagement plus AWS’s own Developer support plan (see https://aws.amazon.com/premiumsupport/ for the tier structure) covers you. Similarly, if you already have two or more engineers who genuinely own operations — pager, patching, restore tests — adding a provider creates a split-brain problem unless the scope split is explicit. And no provider fixes an application that falls over from its own bugs; that is engineering work, not operations.

Common mistakes

  • Buying the reseller layer and assuming operations are included. Consolidated billing plus a support email is not management.
  • Handing over root “to make things easier”. Root sharing is never required for operations and removes your last-resort control.
  • Signing without a responsibility table. Six months later, an unpatched instance gets compromised and both sides point at each other.
  • Judging by dashboard screenshots. Anyone can install Grafana. Ask who was paged last Tuesday at 02:00 and what happened next.

Keeping it under control

  • Keep root credentials, the root email address, and the payer account in your hands, permanently.
  • Review the provider’s CloudTrail activity quarterly — their role’s actions are all logged if you left the trail on.
  • Require a written monthly report: incidents, changes, patch status, backup verification, cost actions.
  • Re-run the verification commands above twice a year; the account should look better each time.
  • Keep your own copy of infrastructure-as-code and runbooks so the relationship stays reversible.

A managed services provider done right makes your AWS account boring: patched, watched, backed up, and cheaper each quarter — while you keep the keys. 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.