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.

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.

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.

The post Cloudar is now Backed by AWS Support: the engineering behind the label appeared first on Cloudar.

In the AWS ecosystem, MSPs take vastly different approaches when building customer-specific landing zones and cloud management platforms. Some approaches preserve your freedom and flexibility. Others quietly build the walls of a gilded cage.

The Two Paths: Open Standards vs. Proprietary Platforms

The Open Approach: AWS Landing Zone Accelerator (LZA)

AWS Landing Zone Accelerator represents the gold standard for customer independence. As an open-source solution built on AWS CDK and CloudFormation, we deploy LZA to provide several critical advantages:

• Complete transparency: All infrastructure is defined as code that you can read, understand, and modify
• No licensing fees: Open-source with no proprietary components
• AWS-maintained: Continuously updated by AWS to keep up to date with new services and features
• Industry standard configuration: With multiple documented sample configurations, you do not need to start from scratch.
• Full customer ownership: Deployed directly into your environment with complete access to the Infrastructure as Code
• Exit-ready from day one: If you ever want to manage it yourself or switch MSPs, you own your landing zone configuration

At Cloudar, we’ve built an entire landing zone practice around LZA precisely because we believe customers should never feel trapped. Your AWS foundation should be an asset you own, not a chain that binds you to any single provider.

The Proprietary Approach: Custom Orchestration Platforms

In contrast, many MSPs have developed proprietary cloud management platforms that create significant lock-in. These are often marketed as “revolutionary” or “next-generation” platforms that promise to make cloud management easier with “just a few simple clicks” or web-based portals that abstract away complexity.

The convenience is real. The long-term cost is hidden.

Here’s what proprietary platforms typically involve:

• Black box deployment: Resources are created through proprietary tooling that abstracts away the underlying infrastructure
• Dependency on custom APIs: Your operations become dependent on the MSP’s platform rather than native AWS tools
• Limited portability: Moving to another MSP or bringing management in-house requires re-platforming
• Knowledge gap: Your team never develops deep expertise in AWS native tools because they’re shielded by the abstraction layer
• Commercial leverage: The MSP knows that switching costs are high, affecting pricing negotiations and service quality over time

The Lock-in Mechanisms You Need to Watch For

1. Custom Landing Zones Without Source Code Access

Some MSPs deploy your resources using “their” landing zone—a pre-configured multi-account setup built with proprietary Infrastructure as Code that remains their intellectual property. When you want to leave, you inherit an AWS environment you don’t fully understand, configured by tools you can’t access.

The Cloudar difference: We can deploy LZA directly into your AWS accounts. Every CloudFormation stack, every configuration file, every security baseline—you have access to it all.

2. Web-Based Orchestrators That Become Operational Chokepoints

Fancy web portals that let you “deploy with one click” sound appealing. Until you realize that every operational change must flow through the MSP’s platform. Want to modify a VPC? You’re dependent on their UI. Need to adjust security groups? Better hope their platform supports your use case.

These orchestrators create operational lock-in: You can’t effectively operate your AWS environment without the MSP’s tooling. You’ve traded AWS complexity for MSP dependency.

3. “Simplified” Interfaces That Hide AWS Reality

Abstraction layers that promise to “make AWS easy” can create a dangerous gap between what you think you’re deploying and what’s actually running in your account. When problems arise—and they always do—you discover that your team doesn’t understand the actual AWS infrastructure because they’ve only interacted with it through the MSP’s simplified interface.

The Real-World Impact of Lock-in

Scenario 1: The Price Increase

Your MSP announces a 30% price increase. With an LZA you own and open standards, you have options: negotiate from a position of strength, bring management in-house, or transition to another MSP in months. With a proprietary platform, you’re looking at risky and arduous re-platforming work—and your MSP knows it.

Scenario 2: The Service Quality Decline

Your MSP gets acquired. The new parent company shifts focus, key engineers leave, and service quality drops. With an open approach, you can transition smoothly. With lock-in, you’re stuck enduring declining service while planning an expensive migration.

Scenario 3: The Strategic Pivot

Your company wants to build internal cloud expertise and eventually self-manage. With LZA, your team can learn standard AWS tools and practices from day one. When you’re ready to transition, you already have the skills and the code. With proprietary platforms, your team has learned the MSP’s tools, not AWS—setting your in-house capability building back by years.

Scenario 4: The Platform Limitation

Your business needs evolve, and you need to implement a complex AWS architecture that isn’t supported by your MSP’s platform. You’re now in the worst position: paying for a platform that constrains you, unable to use native AWS capabilities, and facing the choice between living with limitations or undertaking an expensive re-platforming project.

How to Evaluate Your Current or Prospective MSP

Ask these critical questions:

1. “What landing zone solution do you use?”
   • Red flag: “Our proprietary solution” or vague answers. Subscription based landing zones (yes they exist!).
   • Green flag: “your own AWS Landing Zone Accelerator” or “a per-customer AWS Control Tower with Customizations for Control Tower”
2. “What happens to our infrastructure if we terminate the contract?”
   • Red flag: Vague answers about “transition planning” or “it depends”
   • Green flag: “You keep everything—we’ll help with knowledge transfer, and you’ll have all the code and documentation”
3. “Will our team learn AWS-native tools, or primarily your platform?”
   • Red flag: “Our platform abstracts AWS complexity away”
   • Green flag: “We teach AWS best practices and native tools”

The Cloudar Philosophy: Your Cloud, Your Terms

Here’s what that means in practice:

Full LZA Implementation

Every customer gets its own AWS Landing Zone Accelerator, deployed directly into their accounts with complete source code access to the LZA configuration. Deployments happen in your account, giving you end-to-end visibility on your Landing Zone.

AWS-Native Tooling

We use CloudFormation, CDK, AWS Config, Systems Manager—tools that work with or without us. If you hire another AWS expert or build an in-house team, they’ll recognize everything immediately.

Comprehensive Documentation

You can read about every configuration option today, in the documentation published by AWS. So while we pride ourselves in sharing our knowledge, you are not dependant on us to explain what is going on

Additionally, we write customer-specific documentation  in our Confluence – from architecture decisions to operational procedures.. If you decide to leave, we can provide you with an export of that information.

Open Book Operations

You have full Read Only access to your AWS environment —we’re partners, not gatekeepers. Want to check our work? Go ahead.

Standard AWS Best Practices

We follow AWS Well-Architected Framework principles and industry-standard patterns. No “special sauce” that only we understand.

We succeed by giving you excellent service so you want to stay, not by making it painful to leave.

The Economics of Freedom

Some argue that proprietary platforms are necessary to provide better service or lower costs. We disagree.

Lower costs come from:

• Automation that scales across customers (which we use)
• Deep AWS expertise (which we have)
• Efficient processes (which we’ve refined over years)

Not from locking customers into proprietary platforms.

Better service comes from:

• Highly skilled engineers (which we continuously train)
• Customer focus (which our retention rate proves)

Not from proprietary abstraction layers.

We’ve proven that you can deliver excellent MSP services at competitive prices while keeping customers completely free. In fact, we believe customer freedom makes us better—we can’t coast on lock-in, so we must continuously earn our customers’ business.

Making the Right Choice

Before signing with any MSP, ask yourself:

• Do I understand what I’m getting into? Can you clearly explain how your infrastructure will be deployed and managed?
• What’s my exit strategy if things don’t work out? Is it measured in weeks, months, or years?
• Am I choosing this approach for the right reasons? Is convenience masking a lack of control?
• Do I retain full ownership? Of code, configurations, documentation, and knowledge?

Red Flags in MSP Sales Processes

Be wary if you encounter:

• Heavy emphasis on “simplicity” with little discussion of the underlying AWS architecture
• Vague answers about exit strategies and transition processes
• Marketing focused on proprietary platforms as the primary differentiator
• Contracts that grant the MSP exclusive rights to infrastructure code
• Lack of clarity about what you actually own vs. what you’re licensing

Conclusion: Freedom as a Feature

In the rush to cloud transformation, it’s easy to prioritize speed and convenience. And yes, a well-designed proprietary platform can deploy faster than custom LZA implementation—at least initially.

But cloud strategy isn’t measured in weeks. It’s measured in years and decades. The question isn’t “who can get me to cloud fastest?” It’s “who can help me build sustainable cloud capabilities that serve my business long-term?”

The MSP industry has a pattern: some providers build their business model around customer stickiness achieved through proprietary tooling. They create beautiful interfaces and slick demos that abstract away AWS complexity. Then, months or years later, customers realize they’ve traded AWS vendor lock-in for MSP vendor lock-in—often worse, because at least AWS is standardized.

At Cloudar, we reject this model fundamentally. We believe that customer freedom isn’t a bug to work around—it’s a feature to build for. We’re proud to be an AWS Premier MSP Partner that wins business through excellence, not lock-in.

Your cloud infrastructure is too important to be held hostage by convenient abstractions. You deserve an MSP that treats you as a partner who will grow and evolve, not a captive customer who might someday try to escape.

Choose partners who believe you should always have the keys to your own kingdom. Choose partners who succeed by being valuable, not by being necessary.

Choose freedom.

The post The Hidden Cost of Convenience appeared first on Cloudar.

Interestingly, Roles Anywhere does not completely solve the problem of not needing to create long-lived credentials, instead it moves (and reduces) the problem from credential management (rotation) to certificate management (distribution).

Setting up a Certificate Authority (CA) that can create certificates can be done with AWS Private Certificate Authority, and there are some options out there to manage distribution (usually as part of a bigger Device Management solution), but wouldn’t it be nice if the government of Belgium would do that for us?

The Belgian eID

In Belgium every citizens gets an identity card. The government makes sure that these get distributed and renewed, and since 2005 they contain a chip that holds (among other things) a certificate that can be used for digital authentication. If we can tie this to Roles Anywhere, we don’t have to worry about certificate management ourselves.

This eID is the size of a bankcard and the chip can be interacted with using off the shelf smart card readers. Most information can be read without any additional authentication – if you have the correct middleware, but to sign something you need to enter a PIN code.

The different certificates

Every eID holds an “authentication certificate” that is tied to the owner of the eID and has been signed by the “Citizens CA”.  The Citizens CA’s certificate is in turn signed by the Belgium Root CA . The Root certificate is self-signed. If we trust the Belgium Root CA, we will be able to validate any authentication certificate. More information about this setup can be found at https://repository.eidpki.belgium.be/#/home

The authentication certificate has two pieces of information that are going to be useful to us:

• The Issuer, showing us that the certificate is indeed issued by the Citizen CA.
• The Subject, containing the name and National Number (a number that uniquely points to one person) of the owner.

AWS IAM Roles Anywhere

Roles Anywhere allows you to use a certificate and its private key to get temporary credentials. You can think of it as an AssumeRole call, but instead of starting from an Access Key, we start from a certificate.

There are a few components we need:

• Configuration in our AWS Account, to indicate which CA we trust, and which roles can be assumed by different Issuer and/or Subjects. This also includes the creation of IAM Roles.
• Software on our computer to interact with the Card Reader so we can prove we have access to the eID and know its PIN.

For our use case we are going to trust the Belgium Root CA, and create a Role that can be assumed with any certificate issued by the Citizen CA. We will than limit the permissions of that IAM Role, so it can only write to a unique prefix in S3.

We can do that because every component of the Subject in our certificate gets mapped to a principal tag on the role session. E.g. if the subject is “C=BE, SN=Doe, GN=John, serialNumber=70010112345, CN=John Doe (Authentication)”, we have the following principal tags, and we can use principal tags in any policy.

• x509Subject/C: BE
• x509Subject/SN: Doe
• x509Subject/GN: John
• x509Subject/serialNumber: 70010112345
• x509Subject/CN: John Doe (Authentication)

Putting it all together

In our AWS Account

We will create the following resources in our AWS Account:

• An S3 Bucket
• A trust anchor, configured to trust the Belgium Root CA certificate that is publicly available via https://crt.eidpki.belgium.be/eid/brca6.crt.  This way we can use any certificate created by the Root CA of any of its subordinate CAs (like the Citizen CA)
• An IAM Role, where we configure the trust policy to only allow usage of the Role if:
  • The principal is the Roles Anywhere service (rolesanywhere.amazonaws.com)
  • The Issuer is Citizen CA (aws:PrincipalTag/x509Issuer/CN must equal “Citizen CA”)
  • The source is our trust anchor (aws:SourceArn equals the ARN of the Root CA trust anchor)
• An IAM Policy on this role that allows PutObject acces to all objects that start with the unique National Number (aws:PrincipalTag/x509Subject/serialNumber)
• a (Roles Anywhere) profile that ties the trust anchor to the Role. We could configure more settings here, like a mapping of fields from the certificate or a session policy, but don’t need to.

Of course we do not have to do this by hand, we create a CloudFormation template for this. It can be found in our sample repository: https://github.com/WeAreCloudar/cloudformation-samples/tree/main/templates/roles-anywhere-eid

On our machine

On our machine, we will need – besides the eID and its PIN (at least on macOS, where I tested this):

• a SmartCard Reader
• the Roles Anywhere Credential Helper (downloadable from the AWS Website)
• The AWS CLI (or any other tool we want to use with our AWS Credentials)

We also need a few pieces of information:

• The ARNs of the trust anchor, profile and role we created
• Our own National Number and the name of the bucket (to test our policy)

Ideally we’d be able to configure the credential helper to read any eID we insert, and this is possible if you install the Belgian eID Middleware using the following command.

aws_signing_helper credential-process \
 --trust-anchor-arn $trust_anchor_arn \
--profile-arn $profile_arn \
--role-arn $role_arn \
--certificate "pkcs11:model=Belgium%20eID;object=Authentication" \
--pkcs11-lib '/Library/Belgium Identity Card/Pkcs11/beid-pkcs11.bundle/Contents/MacOS/libbeidpkcs11.dylib

However because of an issue with the helper, this only works on macOS if you build the helper yourself from source. Since we do not want to do that, we can plug in our eID and find and identifier using “aws_signing_helper read-certificate-data”. You should get something like

Matching identities
1) bf013dd57aa34f8f9d4e22ab89dd8eb2 "SERIALNUMBER=70010112345,CN=John Doe (Authentication),C=BE,..."
2) 786f7572198a4a8a82ee7ef3f205d7be "SERIALNUMBER=70010112345,CN=John Doe (Signature),C=BE,..."


Copying everything between quotes, allows us to create a new file, selector.json that looks like this:


[
{
"Key": "x509Subject",
"Value": "SERIALNUMBER=70010112345,CN=John Doe (Authentication),C=BE,..."
}
]

and use that to select our specific certificate:

aws_signing_helper credential-process \
 --trust-anchor-arn $trust_anchor_arn \
--profile-arn $profile_arn \
--role-arn $role_arn \
--cert-selector file://selector.json

Our smart card reader will now prompt us for a PIN. If we enter the right one, we get credentials as output:

{"Version":1,"AccessKeyId":"ASIA...","SecretAccessKey":"COA...","SessionToken":"IQoJ...","Expiration":"2025-03-28T14:16:07Z"}


We can put this command in our ~/.aws/config file, so the AWS CLI will execute it for us, but for testing purposes it’s slightly easier to use the “serve” option.  The AWS Documentation has a longer explanation about how you can use the credential-process: https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html#credential-helper-examples

Testing with s3

In one terminal we can run a credential / metadata server that can be used by the AWS CLI:

~$ aws_signing_helper serve -process \
 --trust-anchor-arn $trust_anchor_arn \
--profile-arn $profile_arn \
--role-arn $role_arn \
--cert-selector file://selector.json


This gives us
2025/03/28 14:28:12 Local server started on port: 9911
2025/03/28 14:28:12 Make it available to the sdk by running:
2025/03/28 14:28:12 export AWS_EC2_METADATA_SERVICE_ENDPOINT=http://127.0.0.1:9911/

We can than use a second terminal to run:

AWS_EC2_METADATA_SERVICE_ENDPOINT=http://127.0.0.1:9911/ aws s3 cp example_file s3://$bucket/serialNumber/70010112345/example_file

and get our file in s3:

upload: example_file to s3://.../serialNumber/70010112345/example_file

Conclusion

This experiment shows that being able to use an external device withIAM Roles, is a very powerful feature, because it can remove a lot of tasks related to certificate and credential management. Being able to do this with something I had in my backpocket made it extra cool.

However, the Belgian eID is probably not the best way to go about this in a real scenario:

• I just gave everyone living in Belgium access to my S3 Bucket. I could use a more scoped-down trust policy, but I would eventually run into limitations of trust-policy size.
• I also didn’t tackle Certificate Revocation Lists (CRL). Every time someone loses their wallet, I would need to invalidate certain certificates – this also runs into size limitations
• I already have a good way to give users access to AWS Accounts, using Identity Center or Cognito.
• The pkcs11 support on macOS seems limited, and I would have to install the middleware everywhere,

This does not mean that Roles Anywhere is not a good solution for this kind of cases:

• If you are already putting certificates on machines (e.g using an MDM solution), AWS IAM Roles Anywhere is a great fit
• Instead of relying on the Belgian Government you can buy an hardware key like a yubikey and use it as your certificate source. This is as secure as using the eID (only the machine with the key plugged in will be able to request credentials), and you would be limiting it to the exact serial number(s) in your trust policy anyway – making CRLs mostly moot.

The post Sign in with your eID: Using AWS IAM Roles Anywhere with a SmartCard Reader appeared first on Cloudar.

AWS has limited responsibility

Yes, AWS takes away a lot of the so-called heavy lifting. They do this by managing all the physical infrastructure and providing Infrastructure as a Service (IaaS). They also go further up the stack and provide you with a managed Microsoft SQL Server (RDS) for example, or a managed NFS (EFS) in what we call Platform as a Service (PaaS). They even offer Software as a Service (SaaS) tools like QuickSight, which is a competitor to the likes of Tableau and Power BI. But there are very clear boundaries between what they do and don’t manage for you.

As you can see in this image of the AWS Shared Responsibility Model, everything in blue is the sole responsibility of the customer. That would be you! And what a huge responsibility it is: I’m sure you’ve heard the horror stories of companies misconfiguring AWS services and leaking confidential data or getting hacked. Or running up their cloud bill to insane amounts in days. Unfortunately those stories are true.

When pitching our Managed Services Offering to prospects, we sometimes get the question why they would need an MSP. Isn’t AWS managing everything already? In this article I’d like to debunk the biggest Cloud Myth: no, AWS does not manage everything, and yes, an MSP will add considerable value to your business. Not in the least because it allows you to focus more on that business, and less on the operational burden of your cloud environments.

You need trained brains

You can see why you would need the proper expertise to adequately manage your AWS environments. Sure, your developers can write your CloudFormation or Terraform code and make sure everything works. But your AWS doesn’t just need to be developed: it needs to be managed. At this point you have two options: either hire and train the staff you need to support and manage your AWS environments, or make use of an MSP.

We find that customers often have a very hard time finding skilled engineers, as there is a high demand for AWS profiles on the market. Keeping them on board once they’re trained is another challenge (recruiters are vicious!). To fully manage an AWS environment around the clock while providing good working conditions for your employees and accounting for the occasional absence, you’ll probably need a team of at least four engineers. Even if you don’t really have enough work for them to do.

The big advantage an MSP has is scale. Instead of all our customers implementing their own services 24/7, we provide them. And instead of hiring, constantly training and retaining qualified engineers, we’ve already got them on board. The service an MSP provides is in most cases cheaper than staffing your own operations, and you no longer have to worry about finding and keeping the talent you need.

Your MSP has got you covered

There are other benefits too: MSPs implement and operate your AWS presence in a Well-Architected way, and offer traditional services like monitoring, a service desk, backups and patching. They also make sure you don’t spend too much and advise you on architectural decisions. Not only will they help define a deployment strategy, they will be your developers’ best friends in a true DevOps kind of way. And last but not least, they’ll keep your environment secure, preferably by using a Cloud Security Posture Management System.

MSPs are trusted partners. We can be yours! To find out more, feel free to get in touch with us.

The post Why you should partner with a Managed Services Provider appeared first on Cloudar.

In IT we have learned to embrace change and new technology. We all need to change if we want our businesses to stay relevant, don’t we? But change, and certainly positive change, doesn’t always happen overnight. It is a process in which we will need to make decisions that will define the desired output.

Since systems, including people and organizations, are interconnected, we have to approach change holistically to make it happen. Therefore, processes exist to guide you during the transformation and help you to arrive at the desired state. In our digital transformation journey and in Cloud Migration it’s not different.

Our approach towards Cloud Migration is a tried and true, structured approach, in which we will first prepare ourselves, then acquire the right methodologies and tools to lay solid foundations and from there on, start practicing and building. During this execution phase, we will iteratively ‘Slice and Dice’ your workloads and business capabilities into reasonable and practical actionables, following an agile approach. Practice makes perfect and before you know it, you’re migrating at scale.

In this perspective, the setup of a highly efficient Migration Factory is utterly important. Here we will make use of the technology and tools at hand to facilitate and automate the migration as much as we can. You can for example make use of CloudEndure, which delivers flexible and innovative migration solutions. Cloudendure offers Continuous block-level replication, cross-infrastructure machine conversion, does automated orchestration and this with a minimal footprint.

Once you’re in the AWS cloud, possibilities to improve, optimize and reinvent are numerous.

Business capabilities will be transformed with available Cloud-Native Services and Technology.

Choosing a partner or MSP that guides you and will help you make the right decisions during the journey, is a direction that you should make as early in the process as possible. It’s an important decision, because once you started your Cloud journey, you will start to see opportunities in which a trusted advisor is a valuable resource to ensure you make the right choices.

Do you want to know where you are in your Cloud journey or where to get started ? Contact your partner for an AWS Migration Readiness Assessment or a AWS Well-Architected Review. It’s a small step, but an essential one to keep your business moving forward in a fast-pace world.

The post Slice and Dice your Cloud Migration and Keep Moving appeared first on Cloudar.

Most often traditional managed services providers offered managed servers. There were some differences in how high in the stack your provider would support you (OS only, some SQL and AD or even full application support), but other than that you were given a server with an OS and what we call the Big Three of Managed Services: monitoring, patching and backups. The provider would also manage the underlying network infrastructure and storage boxes. But that was that. Infrastructure engineers would build your environment, hand it over to you, and you could start deploying your applications.

That infrastructure could be three things. Either dedicated physical servers, a multi-tenant virtualization platform or something that was called private cloud. It wasn’t really cloud, as it didn’t scale. It was just your own virtualization platform. A point also made by Bart Van Hecke: here.

Fast forward some years, and with public cloud, a big shift has been made. Managed infrastructure is no longer the be all and end all of a managed services company. Not only is the whole hardware layer that an MSP used to manage now managed by AWS, but a plethora of new services has been released. The result is that an MSP is now driven higher up in the stack. There is less to manage on the hardware side of things, but much more on PaaS and FaaS level.

A customer now gets a bucket full of Lego, and can start building. You can build beautiful things with Lego. But without any guidelines or help, you can also create the next Frankenstein. So what we see now is that unlike the early days where an engineer would throw a server over the fence and let the developer or application manager do his or her thing, it’s a journey. A journey where an engineer and a developer build things together. You’ve probably heard of this pretty thing called DevOps. It’s much more than just a buzz word. It quickly became the only proper way to move forward and work with the new technologies that AWS kept throwing at us.

As a next generation MSP, Cloudar also has a very solid consultancy business. And that is a match made in heaven. Not only do we take the burden of managing your servers out of your hands, but our skilled engineers help you in deploying your applications in a Well Architected Way. And the virtual infrastructure that comes from that, and is kept in version controlled CloudFormation or Terraform, will also be managed by us. And that is more than just an EC2 instance. It could be a PaaS platform like Beanstalk, ECS or EKS or it could be a FaaS Serverless platform based on Step Functions, Lambda, DynamoDB and API Gateway. Because in the end, developers want to develop and build new things, but they don’t want to manage and nurture what they have built 24*7.

So what we have seen now over the years during many customer engagements, is that we not only manage environments for customers, but we also teach customers how to work better. How to build efficient development pipelines instead of using FTP scripts and a local git to deploy to a static server. How to work together as dev and ops. And in return customers make us better, as they keep coming up with new requirements and new challenges.

The post About MSP’s and Lego appeared first on Cloudar.

The post Cloudar achieves AWS Premier Consulting Partner status appeared first on Cloudar.

Today that clear boundary has disappeared. System engineers are shifting more and more to automation and thus very basic development, or scripting. But at the other side of the spectrum, application engineers and developers are shifting more and more to the infrastructure side. Why? Infrastructure as code. CloudFormation. Boto. Terraform. AWS CDK. In a true public cloud environment, where every single administrative action on infrastructure level is a simple API call, things are changing, and DevOps is born.

You rarely saw devs running around the office with a screwdriver and rack mounts. If they needed a server, they’d ask one to be procured. And waited a few weeks. Now application engineers can quite easily build their own infrastructure to run their applications. It’s just code, right? And they do. Oh boy they do…

However, in most cases it is undesirable to have an application engineer create infrastructure. There is the principle of segregation of duties. Furthermore, it’s very rare a skilled dev has a strong infrastructure background. So while he can probably spin up resources to support his application, the question is: is it Well Architected? And that is where a next gen MSP comes into play. Cloudar was selected by AWS to perform Well Architected Reviews. Our AWS Solution Architect Professional engineers that have followed the required extra training are allowed to perform rigid reviews of existing business critical workloads. Needless to say, each environment we build, needs to adhere to the same Well Architected Principles.

But what if a developer wants to go full serverless, and change infrastructure components rapidly? Things like Lambda’s. Can he wait for an engineer at the MSP to create those resources, throw them away, reconfigure them? Probably not. The cloud allows for speed, and you don’t want your MSP to be a potential bottleneck. Now what?

Here, the answer is again: infrastructure as code. If you demand all infrastructure to be written in code, you can allow your devs to play around in development to deploy extra infrastructure resources. And then when they are happy, and they went through dev and test, and are ready to commit to UAT, insert a code review approval step. Have the engineers that will be actually supporting the environment 24×7 review the infrastructure code. Is what will be deployed to UAT and later on to PRD still Well Architected? Does it adhere to your internal support standards? And for the mental health of the on call engineers: will it be stable and not generate alerts at 3 am in the morning?

So you see that devs will need to work with sysops, and vice versa. Certainly in a project phase. You want to work as agile as possible, but still have a reliable and secure environment. One of the strong points of Cloudar is that we have both. We have a very solid managed services business, but we also have a flourishing consultancy practice. Our people love working with your devs. We like them. Sometimes we even want to cuddle them. Everything it takes to have your workload running 24*7, but reduce your time to market by allowing devs to go crazy until stuff moves to production. Because production, is serious business.

The post A new reality: Devs creating infrastructure. And how to deal with that… appeared first on Cloudar.