Cloudar is now Backed by AWS Support: the engineering behind the label

Cloudar has attained the Backed by AWS Support designation, the label AWS awards to partners certified to deliver AWS Partner-Led Support. We are proud of it, but a label on a website tells you nothing by itself. So instead of only announcing it, we want to show you what we actually built to earn it: the escalation model, the Support API integration in our service desk, and the posture management that feeds our proactive reviews.

The timing also matters. AWS fundamentally restructured its entire support portfolio at re:Invent 2025, and many customers are now re-evaluating how they buy support. So this post does three things: it maps out the new AWS support landscape, explains where partner-delivered support fits in it, and shows what we technically built to earn the label.

First, the lay of the land: AWS Support in 2026

If the plan names below look unfamiliar, that is because the lineup you knew is on its way out. AWS announced at re:Invent 2025 that the legacy Developer, Business, and Enterprise On-Ramp plans will be discontinued on January 1, 2027. The new portfolio is simpler: a free Basic tier plus three paid plans, each layering on the previous one.

Plan	Minimum monthly charge	What defines it
Business Support+	$29 per account	24/7 access to AWS engineers, AI-powered contextual troubleshooting, 30-minute response for critical issues
Enterprise Support	$5,000	Designated TAM, 15-minute response for business-critical cases, AWS Security Incident Response included at no extra cost
Unified Operations	$50,000	The new top tier: Domain Specialist Engineers, AWS Countdown Premium, and proactive operational involvement beyond classic reactive support

Read those numbers as floors, not prices. AWS support has always billed the greater of the minimum or a percentage of your AWS charges (Business Support+ starts at 9% and tiers down as spend grows), so a $29 minimum does not mean a $29 bill. Model your own usage before comparing tiers.

Three changes stand out for anyone planning their 2026 support strategy:

• Full Enterprise Support now has roughly the minimum charge On-Ramp used to. The headline is that the Enterprise minimum fell from $15,000 to $5,000 per month, but the more useful comparison is with Enterprise On-Ramp at $5,500: at a similar floor you now get a designated TAM instead of a pooled one, and a 15-minute critical response target instead of 30 minutes.
• Enterprise On-Ramp disappears by automatic upgrade. On-Ramp customers are moved to full Enterprise Support during 2026, at contract renewal or in batches, gaining a designated TAM and the 15-minute SLA in the process. Check what that does to your spend before the migration lands.
• Business Support+ can be enrolled organization-wide. From the management account (AWS Organizations with all features enabled), one subscription covers the whole organization, which removes the old per-account plan patchwork at the low end.

Two ways to buy support through a partner

Against that backdrop, AWS defines two distinct partner models, and they are frequently confused:

AWS Resold Support means your partner owns the billing relationship, but you keep a direct technical relationship with AWS: you open your own cases in the AWS Support Center. Resold Support is available as Business Support+, Enterprise Support, or Unified Operations. It is a procurement construct more than an operational one.

AWS Partner-Led Support (PLS) means the partner is your support front door. The partner delivers level 1 and level 2, holds Premium Support behind your accounts, and escalates into AWS with priority when needed. This is the model that requires certification, and it is exactly what the Backed by AWS Support label signals: AWS has audited and equipped this partner to run support, not just to invoice it.

The right choice depends on where your operational capability sits. If you have a strong internal cloud team and only want purchasing convenience, Resold Support is the cleaner fit. If you want the team that operates your environment to also own your support cases end to end, PLS is the stronger model. Cloudar offers both, and the rest of this post explains what the PLS machinery looks like on our side.

The Partner-Led Support model

Where direct and Resold Support are two-party models (you open a case, AWS responds, your partner is somewhere on the side), PLS restructures support into a layered model:

1. You contact Cloudar. Our engineers, who already know your landing zone, your accounts, and your workloads, handle the case as level 1 and level 2.
2. Cloudar escalates to AWS when needed. As a PLS partner we hold Premium Support behind your accounts, with 24/7 access to AWS experts and a 15-minute response target for high severity escalations. Worth being precise about what that clock measures: it starts when we escalate to AWS, not when you report the issue to us. Your response times are the ones in your contract with us; the AWS target is what we get once our engineers decide the problem needs AWS on it.
3. AWS works with us, not around us. Our specialist Technical Account Manager collaborates on escalations, and we maintain a jointly defined incident response plan so severity mapping and escalation paths are agreed before an incident, not during one.

The difference with a plain resale construct: a PLS partner is certified, audited, and equipped by AWS to run support, not just to forward tickets. Attaining the label required passing the AWS Foundational Technical Review for our support practice and committing to the program’s response and quality targets. The rest of this post is about the “equipped” part.

Case management: the AWS Support API in our service desk

The first thing we wired in is programmatic case management. Cases we open on your behalf do not live in a console someone checks twice a day; they are synchronized into our Jira-based service desk through the AWS Support API, so the case history and the customer ticket are one timeline.

Opening a case from a ticket:

aws support create-case \
  --region us-east-1 \
  --subject "EKS node group failing health checks after AMI rotation" \
  --service-code "amazon-elastic-kubernetes-service" \
  --severity-code "urgent" \
  --category-code "cluster-management" \
  --communication-body "Managed node group X in eu-west-1 ..." \
  --attachment-set-id "$ATTACHMENT_SET_ID"

Two implementation details that matter if you ever build against this API yourself:

• It only exists in us-east-1. Whatever region your workloads run in, the AWS Support API is accessed through its us-east-1 endpoint. Hardcode the region in your client, not in your mental model of the workload.
• Attachments are a two-step flow. You first call add-attachments-to-set with base64 payloads, get an attachment set ID back, and reference it in create-case or in a later add-communication-to-case. An attachment set holds up to three files at 5 MB each, and the set expires an hour after you create it. Worth knowing before you design around it: the console accepts larger uploads than this API path does, so do not assume a log bundle your engineers can drag into Support Center will go through your automation unchanged.

For the synchronization back into Jira we did not reinvent the wheel. Our case sync is based on JustSupport, the open source tool Just Eat published for exactly this problem: bidirectional sync between AWS Support cases and Jira tickets. The architecture we retained from it is refreshingly simple and worth describing, because it solves the multi-account problem every MSP has:

• The link is a custom Jira field. Each Jira ticket carries a field holding the AWS Support case reference. Fill it in and the sync picks the case up, including a backfill of all prior correspondence (four months of lookback by default), so a case opened in the console before the ticket existed still ends up with a complete timeline.
• Cross-account by role assumption. A scheduled Lambda assumes a lightweight IAM role (deployed from a CloudFormation template in the repo) in every account configured, and pulls case updates from each. One deployment covers the whole managed estate; onboarding a new customer account is one role and one config entry.
• Idempotency via DynamoDB. Processed updates are tracked in a DynamoDB table, so the five-minute polling schedule (chained through SNS until all updates are drained) never produces duplicate comments. It even pauses while an AWS chat session is live and processes the transcript once the session ends.
• Replies go the other way too. An engineer writes a Jira comment starting with #DearAWS and the text is posted to the AWS case; the comment is edited to #SenttoAWS on success. Nobody leaves the ticket to talk to AWS.

Net effect: when an AWS Support engineer replies at 03:00, the update is in the customer-visible ticket minutes later, not when our morning shift logs in.

Resurrecting an eight-year-old serverless project

Full transparency: the upstream repository has been dormant since 2018, three commits and done. You cannot deploy it as-is in 2026, and we would not recommend trying. What we run is an internally maintained version, and getting there was a small case study in how serverless projects age:

• The Lambda runtime was long gone. The Node.js runtime of that era has been through several deprecation cycles since. Moving to a current Node.js LTS runtime was the easy part.
• The AWS SDK migration was the real work. The code was written against the AWS SDK for JavaScript v2, which reached end of support in 2025 and is not bundled in current Node.js Lambda runtimes anyway. Migrating to SDK v3 meant swapping the monolithic client for modular ones (Support, DynamoDB, SNS, STS) and rewriting the .promise() call chains around the v3 command pattern.
• Jira moved underneath it. The Jira Cloud REST API has evolved since 2018; the gotcha that costs the most time is that modern comment endpoints expect Atlassian Document Format JSON rather than plain text, so the comment-posting path needed reworking on both directions of the sync.
• The deployment tooling needed a refresh. The original Serverless Framework configuration predates several major versions; we redeployed on a current toolchain.

Here is the part worth internalizing: the core architecture needed no redesign. Runtimes, SDK clients, API payloads and deployment tooling all had to be replaced, but the shape of the solution did not: the custom field linkage, the cross-account role assumption, the SNS-chained processing and the DynamoDB idempotency table all still work exactly as designed in 2018. The runtimes, SDKs, and APIs around it rotted; the event-driven design did not. That is the strongest endorsement of simple serverless architecture we can give, and it is why we chose to revive the project rather than build our own. If you want to do the same, the upstream repo remains a solid architectural blueprint, but budget for the modernization pass rather than a quick deploy.

One design decision worth stealing: we keep a hard mapping table between AWS severity codes and our ITSM priorities, agreed in the incident response plan with our TAM.

AWS severity code	Response target	Cloudar priority
critical	15 min	P1
urgent	1 hour	P2
high	4 hours	P3
normal	12 hours	P4
low	24 hours	P5

Sounds obvious, but during an incident nobody should be interpreting what “urgent” means. The mapping is code, not judgement.

Proactive posture: CSPM across the managed estate

PLS pushes partners toward proactive support: catching problems before they become cases. For posture, our tool of choice is Trend Vision One Cloud Risk Management, the CSPM that carries the Cloud One Conformity lineage. It is a third-party platform, but its mechanics are AWS all the way down, which is exactly why it works well at MSP scale:

• Onboarding is a CloudFormation stack. Each managed account gets a read-only cross-account IAM role deployed from a template, the same pattern as our case sync. New customer, one stack, done. No agents for posture scanning.
• Coverage is broad and rule-based. The platform continuously evaluates accounts against 900+ AWS-specific rule checks, mapped to the Well-Architected Framework and to the compliance frameworks our customers actually get audited on. That mapping matters: a finding that says “S3 bucket policy allows cross-account write, fails CIS 2.1.x and your ISO 27001 control” is actionable in a way a raw misconfiguration list is not.
• Findings flow into the same operational rhythm. Posture findings are triaged into our service desk with the same priority model as reactive cases, so a critical misconfiguration is a P1 with an owner, not a dashboard entry. For customers running AWS Security Hub, findings can be published there as well, keeping their native AWS view complete.

This is also where the PLS program features land in practice. The Partner Security Reviews the program includes, aligned with the Well-Architected Security Pillar, are fed directly by this CSPM data rather than assembled by hand. And for the reactive path, PLS grants secure access to a subset of the diagnostic tooling AWS Support engineers themselves use, which shortens the loop on the classic “we need service-side visibility” cases that previously required a full escalation round-trip.

How you would build this AWS-native

Because this is the question every architect should ask before buying anything: what does the same capability look like with AWS-native services? Since the re:Invent 2025 restructure, the native stack looks like this:

• AWS Config is the foundation. A configuration recorder per account and region tracks resource state, and managed Config rules evaluate it continuously. Conformance packs bundle rules into deployable compliance sets (CIS, PCI, operational best practices), and an aggregator gives you the cross-account view.
• Security Hub CSPM is the posture layer, and the naming is worth getting right. The posture management capabilities previously known as AWS Security Hub are now AWS Security Hub CSPM: best practice checks against standards like AWS Foundational Security Best Practices and the CIS AWS Foundations Benchmark, producing findings in the AWS Security Finding Format. The name AWS Security Hub now refers to the broader unified service, generally available since December 2025, which correlates and enriches signals from Security Hub CSPM, GuardDuty, Inspector and Macie into prioritized risks. So it is not a rename: the old service became the CSPM component inside a bigger one.
• Organizations does the fleet wiring. A delegated administrator account plus central configuration policies auto-enable the services and standards on every new account in the organization, so posture coverage is a property of account creation, not a checklist item.
• Remediation is EventBridge plus SSM. Findings emit events; rules route critical ones to SSM Automation runbooks or ticket creation. Config also supports auto-remediation directly on rule breach.
• Amazon GuardDuty adds the threat detection layer. Posture tells you an environment is configured badly; it does not tell you a credential is being abused right now. GuardDuty answers that second question, analysing CloudTrail management and data events, VPC flow logs, and DNS query logs with no agent to deploy and no log pipeline to build. Well worth enabling alongside the stack above, with the optional protection plans (S3, EKS Runtime Monitoring, Malware, RDS, Lambda) switched on selectively rather than everywhere, since billing scales with the volume of events and logs analysed.

For a single organization, this stack is excellent and should be the default before any third-party purchase. So why do we run a third-party CSPM as an AWS Premier Partner? Two structural reasons, and one commercial one:

• The organization boundary. Native aggregation (Config aggregators, Security Hub delegated admin, and GuardDuty’s delegated administrator too) works within one AWS Organization. An MSP manages many customers, which means many organizations. GuardDuty has exactly the same limitation: you get clean organization-wide enablement and auto-enable for new member accounts, but only within each organization, so a partner still ends up with one delegated administrator per customer and no native way to see across them. Building one consolidated, customer-partitioned view means custom plumbing: forwarding findings to a central EventBridge bus and building your own aggregation, storage, and access model on top. At that point you are not configuring a service, you are building a product.
• Compliance mapping out of the box. Our customers get audited against ISO 27001, NIS2, and sector frameworks. The third-party platform ships the rule-to-framework mapping and the auditor-friendly reporting; natively you assemble that from conformance packs and Audit Manager per organization.
• The cost shape is worth modelling, not assuming. Config bills per configuration item recorded and per rule evaluation, Security Hub CSPM per check. That means native posture spend scales with how much your customers change their environments rather than with how many customers you have, which is a harder number to forecast in a managed services P&L. We are deliberately not putting a figure on the comparison here, because it depends entirely on resource churn in the estate you are modelling. Run it against your own account inventory before treating either option as the cheap one.

None of this makes the native stack wrong; it makes it right for a different shape of organization. If you run one AWS Organization, start with Config, Security Hub CSPM, and central configuration, and only look further when you hit a concrete limit. Our estate hits the multi-organization limit on day one, so we run Trend Vision One across it, and keep the AWS-native integration points (CloudFormation onboarding, CloudTrail-driven signals, optional Security Hub publishing) so nothing about the estate becomes opaque to AWS tooling.

And to be clear about where we would like this to go: as Cloudar, we would love to see AWS close this gap. First-class multi-organization support in Config aggregators, Security Hub CSPM, and GuardDuty, letting a partner operate one governed view across the organizations of the customers it manages, would remove our biggest reason to depend on third-party tooling for posture. The building blocks (delegated administration, central configuration, cross-account roles) all exist; they just stop at the organization boundary today. Consider this our feature request, filed publicly.

What this means for you

For Cloudar, the label validates an investment: AWS-grade tooling, a curated troubleshooting curriculum built from the cases AWS Support escalates most often, and a TAM relationship that spans our whole managed base. Support is core to what we sell, and this gives that investment external AWS validation rather than asking customers to take our word for it.

For you as a customer, the practical outcomes are:

• One front door, with context. You reach the engineers who operate your environment, backed by the pipelines described above rather than an anonymous queue starting from zero.
• AWS speed when it counts. When something needs AWS, our escalation reaches their experts under a 15-minute response target, with the diagnosis already framed rather than starting from scratch.
• Proactive by construction. Posture findings and security reviews flow through the same priority model as your incidents, so misconfigurations become owned tickets instead of dashboard entries.

With the legacy plans disappearing on January 1, 2027, every AWS customer currently paying for one of the retiring plans will touch this decision in the coming year: pick a new direct plan, buy Resold Support through a partner, or move to Partner-Led Support. If you currently run a direct plan next to a partner relationship, that re-evaluation is worth a structured conversation: consolidating typically simplifies contracts, escalation paths, and often the bill. And if you are a partner reading this on your own PLS journey, the Support API, a revived open source case sync, and a severity mapping your team never has to debate at 03:00 are the places to start.

Program details live on the AWS Partner-Led Support page.

AWS Support, CSPM, MSP, Partner-Led Support