If you have never heard of the VDDK, that is normal. It is a C library, not a product. It is also the component that lets software outside the hypervisor open a VMDK and read blocks out of it. Combined with Changed Block Tracking, it is what makes agentless migration and agentless backup possible at all. Take it away and a large part of the tooling that reads VMware disks from the outside stops being installable.

Plenty of platforms are affected. This post is only about one of them: AWS. If you are running vSphere and you have been telling yourself that the migration project can wait another budget cycle, this is the part where the calculation changes.

What actually broke on the AWS side

AWS Transform MGN, still widely known as AWS Application Migration Service, offers two replication methods for VMware sources.

Agentless snapshot-based replication runs through the MGN vCenter Client, a software bundle you install on a dedicated Linux VM inside your vSphere environment. It discovers your VMs through vCenter, then for each replication run it takes a VMware snapshot, uses CBT to work out which blocks changed, and reads those blocks with the VDDK before shipping them to AWS.

The VDDK is not bundled with the client. It cannot be, because the licence forbids redistribution. You supply it yourself. The AWS documentation is explicit about the version:

You must log in to your Broadcomm account and download VDDK 7.0.3.3 to the VM on which the MGN vCenter Client is installed. VDDK 7.0.3.3 must be used, regardless of the vCenter version used.

The installer takes it as a parameter, --vddk-path, pointing at the tarball on local disk.

That is the whole problem in one line. VDDK 7.0.3.3 is a 7.0 line release. The 7.x downloads were already unreliable before August, and now the entire download tree is gone. As of writing, that documentation page is unchanged and still tells you to go and fetch a file that cannot be fetched. AWS has published nothing about the change: no bulletin, no what’s-new post, no documentation update. So a customer starting a greenfield agentless deployment today follows the runbook, hits a dead link at step four, and has no official guidance telling them why.

Agent-based replication installs the AWS Replication Agent inside the guest OS. It reads blocks through its own kernel-level driver, talks directly to a replication server in your staging subnet, and never touches the VDDK, vCenter or VMware snapshots. Nothing about it changed on 25 August.

Two things follow from that, and they matter more than the headlines suggest.

First, the practical damage on AWS is narrower than on platforms whose only migration path was VDDK-based. AWS’s own FAQ has said for years that agent-based replication is the default recommendation for all use cases, with agentless reserved for the exceptions: security policy that forbids installing agents, or an OS the agent does not support. The supported operating system lists for the two methods are in fact identical, so in practice the exception is almost always the policy one. Broadcom removed AWS’s fallback, not its main road.

Second, “narrower” is not “none”. If you are the organisation whose change board does not allow third-party agents in the guest, or you inherited an estate where nobody has working credentials for a few hundred VMs, agentless was the answer and it is now gone for new installs.

One nuance worth stating plainly because we have not seen AWS confirm it: an existing vCenter Client installation already has the VDDK on disk, and the client auto-updates itself independently of the VDDK. Running replications are not expected to break. But rebuild that VM, move to a new AWS account, or add a second vCenter environment, and you are back at the 404. Treat every existing vCenter Client as a single point of failure you can no longer reprovision.

Four routes to AWS that do not need a download from Broadcom

1. Agent-based MGN, deployed at scale with the MGN connector

The reflex objection to agent-based migration is that somebody has to log into every VM. That was true a few years ago. It is not the current state of the tooling, and this is the single most useful thing to know if the VDDK removal is what pushed you into a decision.

The MGN connector is a Linux VM in your source environment, registered to AWS through a Systems Manager hybrid activation, that pushes the replication agent out to your source servers for you. You give it network reachability to the sources and a set of source credentials in AWS Secrets Manager, and it handles prerequisite validation, installation on both Windows and Linux, and post-install verification. Installation of the connector itself takes a couple of minutes and is a one-time task per source environment. AWS Transform will now generate the IAM roles, the hybrid activation code and the ready-to-run install command for you through its console flow, or hand you a CloudFormation template if you would rather own the IAM yourself.

For the servers the connector cannot reach, the manual install is a single command. On Linux:

wget -O ./aws-replication-installer-init \
  https://aws-application-migration-service-eu-west-1.s3.eu-west-1.amazonaws.com/latest/linux/aws-replication-installer-init

chmod +x aws-replication-installer-init

sudo ./aws-replication-installer-init \
  --region eu-west-1 \
  --user-provided-id vm-prod-app-014 \
  --no-replication \
  --no-prompt

Two flags earn their keep on a large migration. --user-provided-id sets the identifier MGN uses to recognise the server consistently, which is also what AWS Transform keys on when it maps your inventory into wave plans, so set it at install time rather than trying to reconcile later. --no-replication installs without starting the data flow, which lets you pre-stage agents across hundreds of servers and then switch on replication wave by wave instead of saturating your uplink and your MGN quotas on day one.

Validate the installer hash before you push it estate-wide. It is published per region alongside the binary.

What you need in place, and what tends to be the actual project work rather than the agent install:

• Outbound TCP 443 from every source server to the regional MGN endpoint, and TCP 1500 to the replication servers in your staging subnet. PrivateLink over Direct Connect or Site-to-Site VPN if the data must not cross the internet.
• A staging area subnet with routing to S3, since the replication server fetches its own components from there. This is the single most common cause of a replication that installs cleanly and then stalls.
• Root or administrator on each guest. The Linux installer creates an aws-replication user and adds it to sudoers, and fails if it cannot.
• Kernel headers on the Linux guests matching the running kernel.

The compensation for the extra guest-level work is real: continuous block-level replication rather than periodic snapshot shipping, which means a cutover window measured in minutes instead of waiting for a final snapshot to complete, and no VMware snapshots sitting on your production datastores slowing disk performance during the whole migration.

2. The cached tarball, with a caveat you should not skip

If someone in your organisation still has VMware-vix-disklib-7.0.3.3-*.tar.gz on a build host, a backup appliance or an old runbook attachment, it will still work. The installer only wants a path. Checksums for the 7.0 and 8.0 lines are recoverable from cached copies of the portal, so verify what you hold rather than trusting the filename.

The caveat: Broadcom’s own wording to customers is that the VDDK is no longer available for use or download. Not just download. We are not lawyers and this is not legal advice, but if your plan depends on a cached copy of a proprietary library whose vendor has just told customers it is not available for use, that is a question for your legal team before it becomes a question for your auditor. Ask it now, not the week before cutover.

3. Offline export through VM Import/Export

This is the path that needs no VDDK and no agent at all. Export the VM from vSphere as an OVA or a stream-optimised VMDK using vCenter’s own export function or OVF Tool, upload it to S3, and import it as an AMI:

aws ec2 import-image \
  --disk-containers Format=ova,UserBucket="{S3Bucket=my-import-bucket,S3Key=vms/app014.ova}"

You need an IAM service role named vmimport with a trust policy for vmie.amazonaws.com and permissions on the source bucket and on EC2. Supported input formats are OVA, VMDK, VHD, VHDX and raw.

Be honest with yourself about what this path costs before you make it the plan for more than a handful of servers:

• No CBT, so every attempt is a full copy. A failed import is a full re-copy.
• Staging storage for the exports, on-premises and in S3, sized for your largest VMs.
• Real downtime, because you export a powered-off or quiesced VM and there is no delta sync afterwards.
• Genuine limitations. VMs using Raw Device Mapping are not supported, only VMDK disk images. Encrypted volumes are not supported. Dual-boot configurations are not supported. Neither is the VMware SEsparse delta-file format, nor arm64. Machines that got where they are through a physical-to-virtual conversion are not supported. There is a defined supported-OS matrix and older or unusual guests fall outside it.

VM Import/Export is a good tool for a controlled set of appliances and stragglers. It is not a replacement for a replication-based migration of a few hundred workloads, and anyone who tells you otherwise has not tried it at that scale.

4. Stop moving the VM

The uncomfortable observation in a lot of migration assessments is that a meaningful slice of the estate should not be rehosted at all. A file server becomes Amazon FSx or S3 with DataSync doing the copy. A SQL Server or Oracle instance becomes an RDS instance with AWS DMS handling the load and change data capture. An application server that was built by hand in 2016 gets rebuilt from a pipeline, which is faster than debugging why its agent will not install.

None of those paths care about the VDDK, because none of them read the virtual disk. If your agentless plan just died, this is a good moment to re-run the assessment and ask which VMs you were only lifting because lifting looked cheap.

What to do in the next two weeks

1. Inventory what you hold. Search your build hosts, backup appliances and documentation attachments for VDDK tarballs. Checksum them. Treat them as assets with an expiry date, and get the licensing question in front of legal.
2. Check whether you actually have an existing vCenter Client. If yes, freeze it. No rebuilds, no account moves, no second environment, until you have a tested alternative.
3. Test the agent on your hardest 5 percent. Not your easy Linux fleet. The 2012 R2 box nobody logs into, the appliance with a vendor-locked OS, the VM whose kernel headers are missing. Those are the servers that will decide whether agent-based works for you, and you want to know in September, not in March.
4. Exercise the OVA path once, deliberately. Export one real VM, import it, boot it, log in. A fallback you have never run is not a fallback.
5. Put the date on the wall. General support for vSphere 8 ends on 11 October 2027, with technical guidance running to 2029. That is your outer bound, and it is closer than it looks once you subtract assessment, network design, wave planning and testing.

The pattern is the point

Broadcom is reportedly bringing back a refreshed vSphere Standard aimed at smaller estates, discussed in interviews at VMware Explore rather than announced from a stage, with details promised in October. Read alongside the VDDK removal, the two moves are hard to reconcile as a coherent retention strategy. One says come back, the smaller edition is being looked after. The other quietly removes a dependency that the entire third-party exit ecosystem was built on, with no notice and no replacement.

Whatever the intent, the operational conclusion is the same. The technical routes off vSphere are being narrowed, not widened, and they are being narrowed without warning. The VDDK went away on a Tuesday. Nothing says the next dependency will give you more notice.

If you are going to leave, the cost of leaving is lowest while you still have working tooling, a supported hypervisor version, and time to test. That window is not open indefinitely.

Where Cloudar fits

We have done this often enough to know which parts of a VMware to AWS migration are the hard parts, and the disk copy is rarely one of them. The hard parts are the dependency mapping nobody documented, the network translation, the wave sequencing, the servers that resist every automated approach, and the operational handover afterwards. We work through those with AWS Transform and MGN where they fit, and around them where they do not.

If the VDDK removal has just invalidated your migration plan, or if it has made you realise you did not have one, our AWS migration practice is the place to start. We are an AWS Premier Partner and Migration Competency partner based in Belgium, and we would rather assess your estate honestly than sell you a lift-and-shift you will regret.

For the strategic side of the same question, why the timing of your VMware exit matters as much as the mechanics, see Leaving VMware is a question of timing.

All AWS documentation references were verified on 8 September 2026. AWS had published no guidance on the VDDK removal at that point, and the MGN vCenter Client requirements page still instructed customers to download VDDK 7.0.3.3 from Broadcom.

The post Broadcom just removed the VDDK. Here is how you still get from VMware to AWS. appeared first on Cloudar.

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.

When companies make an IT decision, they look at licensing costs, implementation costs, sometimes training costs. What they rarely calculate is what we’ve jokingly come to call the sigh surcharge. It’s the sum of human friction that arises when systems aren’t set up optimally. It’s the second of hesitation before a too-slow action. It’s the workaround everyone in a company knows about but nobody has actually fixed. It’s the copy-paste from one system to another because the integration never happened. It’s the mental weight of working against your tools instead of with them.

A single sigh seems trivial. Collectively, it’s the unspoken productivity leak that drains away quarter after quarter. Fortunately for most companies, it’s the one surcharge that never shows up on an invoice. But imagine if it did? That, just like VAT, a sigh surcharge got added to every software decision. A percentage on top of the implementation cost reflecting the expected human friction. Poorly designed interface? +15% sigh surcharge. No integration with existing tools? +20%. Slow load times at critical moments? +10%. Illogical workflows that clash with how people actually work? +25%. Suddenly the cheapest option looks a lot more expensive. And at that point, the solution that was actually implemented properly – with thoughtful workflows, meaningful automation, and a user experience that doesn’t get in people’s way – starts to look a lot more appealing.

The sigh is a signal

Every sigh is really a data point. It’s feedback nobody asked for but that’s given constantly. It says: this isn’t right, this isn’t working. This costs me more energy than it should. In organizations where the technology works well, you barely hear that sigh. Not because people stop sighing about other things, but because the tools simply do what they’re supposed to do. To some, that might sound like a luxury. To us, though, it’s the baseline that people deserve from the systems they work with every day.

And fortunately, you don’t need to be a data scientist to interpret these data points. The first step is simple: head over to the coffee machine. Stand there for a few hours and find out what people complain about most. They’ll point you straight to the biggest source of frustration. A second step is to look within the organization for the biggest workaround-builders — the people who, for every decision, already have a plan B or C in mind. In IT terms: look at all those Excel sheets patching a “gap” somewhere, because no automated process exists. Or all the emails that could really just have been a notification. They’re disguised examples of a sigh. And once you add up all these moments and multiply them by the number of people frustrated by the same bottleneck every day, the sigh surcharge starts to turn into a number you can actually put on a slide.

At Cloudar, we believe technology works best when it’s invisible. When people can simply do what they’re good at, without having to think about the tools that are supposed to help them. That doesn’t always mean choosing the most expensive option. It does mean making the right choice and executing it well. Because a cloud solution that’s only half implemented, or whose configuration doesn’t match how people actually work, doesn’t deliver value. It delivers sigh surcharges. The real return on investment of a good implementation isn’t just speed or cost savings. It’s, above all, a sound you no longer hear on the work floor.

The post The sigh surcharge appeared first on Cloudar.

AWS: the choice that determined everything 

In the cloud industry, “focus” is a dangerous word. It sounds great in a pitch deck, but in practice it means leaving opportunities on the table. Customers running on Azure, projects you have to refer elsewhere, RFPs where you know from the start you won’t win. We accepted that over the years. Our drive was (and still is) simple: by concentrating everything on one platform, we can become the best possible partner on it. Not broad, but deep. That translates concretely into certifications, into architectural knowledge, into the relationships you build with the AWS team… and ultimately into the trust that customers place in you for their most critical workloads. Becoming an AWS Premier Partner was a milestone in that journey. But it was never the endpoint, let alone the ultimate goal. 

With the rise of generative AI, the role of cloud architecture has fundamentally changed. The question is no longer “how do we migrate our workloads to the cloud?” but “how do we design infrastructure that can run AI models at scale, securely, cost-efficiently and with the right governance?” That is an architectural challenge of an entirely new order. Inference costs, latency optimisation, data residency, IAM configurations compatible with foundation models, VPC setups that withstand enterprise compliance: these are the problems our customers face. And these are the problems for which you need to know AWS to the bone. 

AWS Bedrock has become the platform in that landscape where enterprise AI adoption takes place in practice. Not because it is the only option, but because it is the option that takes security, compliance and integration with existing AWS workloads seriously. For organisations that have been running on AWS for years, Bedrock is the most logical bridge to production-ready AI. 

What Anthropic Authorized Reseller status concretely means 

I’ll be honest: it took quite some effort. The Anthropic Authorized Reseller status is not a badge you apply for and receive in the post a week later. It requires knowledge, skill, a demonstrable pipeline and navigating an approval process in which Anthropic itself decides whether you clear the bar. A handful of AWS partners worldwide manage that. Most do not. And we are now the first local Benelux player to join that group. 

What this concretely means for the Benelux market is perhaps less well known than it should be. Since October 2025, AWS requires that a customer’s managing partner be officially recognised by Anthropic, if that customer wants access to the latest Claude models via Bedrock. This applies to Claude 4, Claude Code, and all future frontier models. Without a recognised partner: no access. 

In practice, this meant that large organisations in the Benelux were faced with a closed door for months. They wanted to experiment with the most capable models on the market, had the budget, had the use cases, but had no AWS partner with the right status. For CTOs, CIOs or enterprise architects who take AI seriously, there are a few practical implications worth mentioning. 

• First: access to frontier models has become a partnership question, not just a technical or commercial one. The architectural choices you make today – which AWS partner manages your account, how your Bedrock setup is configured – partly determine which AI capabilities you can deploy tomorrow. 

• Second: enterprise seats for Anthropic are not the same as API access. It is about onboarding, governance, user management and monitoring data flows within your own AWS environment. That requires someone who knows both the Anthropic side and the AWS infrastructure. 

• Third: Claude Code is a relevant example of where this is heading. AI-driven code assistance running directly on your own AWS infrastructure, without your code leaving the perimeter of your own environment. That is a different proposition from a SaaS tool with a subscription. 

In 2014 we chose AWS because we believed that focus leads to expertise, and expertise leads to trust. In 2025 and 2026, AI has not changed our conviction. The complexity of production-ready AI at enterprise scale requires precisely the kind of deep platform knowledge we have invested in over the past twelve years. 

The Anthropic Authorized Reseller status is, in that light, not just a commercial milestone. It is the validation that our approach works. And for our customers, it is the guarantee that they can get started with the most advanced AI models on the market, guided by a local team that knows the full stack: from infrastructure to model deployment to governance. But as has been said before, for us this is far from the final destination. 

The post Blood, sweat and tears appeared first on Cloudar.

It is the most primitive cost optimization imaginable, and the fact that people reach for it tells you exactly where AI operations are heading. Developers are willing to make their assistant grunt like a Neanderthal to trim a few thousand tokens off a session. Something changed to make that feel worth doing.

For the past two years, most of us have been running AI workloads on someone else’s dime. Flat-rate subscription plans made generative AI feel free at the point of use. Fire off as many prompts as you want, let your coding agent churn through refactors overnight, and the bill stays the same.

That era is ending. LLM providers are increasingly pushing heavy workloads toward usage-based pricing, credits, stricter rate limits, or token-metered APIs, and the reason is simple: the plans were too cheap. The compute behind a heavy agentic workload costs real money, and providers can no longer subsidize power users with the margins of light users. Rate limits are tightening, “unlimited” tiers are disappearing, and token-based billing is becoming the norm.

If you have ever watched an AWS bill balloon because nobody rightsized their EC2 fleet, you know exactly what happens next. The token is the new gigabyte, and we are about to relive the FinOps learning curve, this time for AI.

That is why we need FinAIOps: FinOps for AI systems, where LLMOps meets cost discipline in production. It is the practice of running AI workloads with the same operational and cost rigor we apply to everything else in the cloud.

Lessons from building agents in production

At Cloudar we have been building and running agentic AI workloads in production. Doing that teaches you very quickly where tokens go to die. These are the practices that made the biggest difference.

1. Use smaller models for simpler tasks

Not every task needs your most capable model. Agent routing, classification, and simple extraction run perfectly well on smaller, cheaper models. Reserve the frontier model for the reasoning-heavy steps. The per-token price difference between a frontier model and a small model on Bedrock is easily an order of magnitude, so a lightweight router that dispatches work to the right specialist pays for itself immediately.

This is where Amazon Bedrock shines: switching between model families and sizes is a configuration change, not a re-architecture. You can experiment with the cost and quality trade-off per task and measure the result.

2. Gatekeep the agent: deterministic first

The cheapest LLM call is the one you never make. If a task can be solved deterministically, solve it deterministically. Fetching a metric, checking a threshold, parsing a known log format: none of that needs an agent. Put a gate in front of your agent that handles the predictable cases with plain code and only escalates genuine ambiguity to the model.

3. Keep prompts compact

Prompts are tokens, and tokens are money. Every instruction, every example, every “please be helpful and thorough” costs you on every single invocation. Ruthlessly edit your system prompts. Say what you need, cut what you do not, and test whether shorter prompts degrade quality. Usually they do not.

4. Limit the tools your MCP servers expose

This one is underestimated. Every tool definition you expose to an agent is injected into the context on every call. It might feel convenient to give your agent the full toolbox, but a wall of tool schemas eats tokens before the agent has done any actual work.

Only expose the tools the agent genuinely needs. And when you do not know upfront which tools an agent will use, for example with open-ended investigative workloads, take an iterative approach: expose everything, have the agent write a short analysis after each run, and after a set period feed those results to an advanced model to analyze which tools earn their place and which can be dropped. Treat your tool catalog like an IAM policy: least privilege, reviewed regularly.

5. Cap the loop

Agentic workloads can run away. An agent stuck in a retry loop is the token equivalent of a Lambda retry storm. Set a maximum number of steps and tool calls per run, and a hard token budget per invocation. Fail loud, not expensive.

6. Mind your outputs and your history

For many frontier models, output tokens are priced significantly higher than input tokens. Ask for structured output instead of prose, set max_tokens deliberately, and instruct the model to be terse. And do not drag the full conversation history through every turn: summarize or window older context, because in long-running agents the context snowballs and you pay for all of it on every call.

7. Use prompt caching

On Bedrock, prompt caching lets you cache the static parts of your context, such as system prompts and tool definitions, and pay a fraction of the input price on subsequent calls. If you have a large tool catalog you cannot trim further, caching softens the blow considerably. Combined with point 4, this is one of the highest-impact optimizations available today.

8. Batch what is not urgent

Amazon Bedrock batch inference runs asynchronous workloads at a 50 percent discount compared to on-demand pricing. You submit a JSONL file with your prompts, Bedrock processes them asynchronously, and the results land in S3, typically within 24 hours. Periodic analysis jobs are a textbook example: nobody is waiting on the result, so there is no reason to pay real-time prices for it.

Bedrock also offers a Flex service tier for supported models, trading latency for lower cost. Unlike batch, Flex uses the regular invocation API: you add a service tier parameter to your call and accept increased latency in exchange for the lower rate. Availability and discount levels depend on the model and tier, so check the current pricing page before assuming the same economics as batch. It is a good fit for background agent runs that are real-time in shape but not in urgency.

The practices above, at a glance:

Measure it or it did not happen

Optimization without measurement is guesswork. Two AWS capabilities matter here.

Amazon CloudWatch gives you deep visibility into every dimension of your Bedrock usage. Bedrock publishes runtime metrics to the AWS/Bedrock namespace, with ModelId among the available dimensions. Which dimensions apply, and whether ModelId alone is enough, depends on the model, Region, service tier, and whether you invoke through an inference profile, so treat any dashboard as a starting point rather than a template that works unchanged everywhere. The ones to watch:

• Invocations: how often each model is called
• InputTokenCount and OutputTokenCount: where your money actually goes
• InvocationLatency: the quality side of the trade-off
• InvocationThrottles and InvocationClientErrors: the signals that an agent is misbehaving

Build a dashboard on these, and set an alarm on token consumption. For example, a CloudWatch alarm on the hourly Sum of OutputTokenCount per model catches a runaway agent loop within the hour instead of on next month’s invoice:

aws cloudwatch put-metric-alarm \
  --alarm-name bedrock-output-token-spike \
  --namespace AWS/Bedrock \
  --metric-name OutputTokenCount \
  --dimensions Name=ModelId,Value=<your-bedrock-model-id-or-inference-profile> \
  --statistic Sum --period 3600 \
  --threshold 5000000 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:eu-west-1:123456789012:ops-alerts

Replace the model ID with the exact model or inference profile dimension used in your account, since Bedrock model IDs are versioned and vary by Region and provider. Enable model invocation logging as well, so you can see the actual prompts behind an anomaly. Treat anomalous spend like any other operational incident.

Bedrock application inference profiles let you tag usage per agent, per workflow, or per customer. You create a profile that wraps a foundation model, attach cost allocation tags, and invoke through the profile ARN instead of the model ID:

aws bedrock create-inference-profile \
  --inference-profile-name customer-a-investigator \
  --model-source copyFrom=arn:aws:bedrock:eu-west-1::foundation-model/anthropic.claude-sonnet-4-5 \
  --tags key=customer,value=customer-a key=agent,value=investigator

Those tags flow through to Cost Explorer and CloudWatch, turning “the AI bill is high” into “agent X on task Y for customer Z is driving the cost.” For a managed service provider, this is essential: it enables proper chargeback and shows customers exactly what their AI workloads cost.

Finally, track the metric that actually matters: cost per outcome. Tokens per completed task beats tokens per month. An agent that uses three times the tokens but delivers twice the results is the cheaper agent. That is the KPI that makes FinAIOps a business discipline instead of a savings exercise.

The bill is coming. Be ready.

The shift from plans to tokens is not a pricing tweak, it is a forcing function. Teams that treat AI as free will get the same surprise bills we saw in the early cloud days. Teams that apply FinAIOps discipline, right-sized models, gated invocations, lean prompts, curated tool catalogs, caching, batching, and real cost attribution, will run AI workloads that are both powerful and predictable.

We learned the hard way with EC2 that capacity discipline pays off. Let us not learn it the hard way again with tokens.

The post FinAIOps: Why Token Economics Will Define Your AI Operations appeared first on Cloudar.

When Broadcom closed its acquisition of VMware, everyone in the industry knew something was going to change. Have we already forgotten what happened to Symantec, among others? Broadcom bought Symantec’s enterprise unit in 2019, narrowed it to around 2,000 of the largest accounts (the Global 2000), and raised prices on most of the rest. VMware is the same script on a bigger stage. The only surprise was how fast it came. In short order, perpetual licenses were scrapped, thousands of cloud partners (Cloudar among them) received a termination letter, and a catalogue of over 8,000 SKUs was reduced to two bundles (VMware Cloud Foundation and VMware vSphere Foundation). The shift from per-CPU-socket licensing to per-physical-core licensing also meant that organizations expecting to simply carry on with an existing installation were suddenly facing invoices two to five times higher.

But those cost increases are relative. The real impact only lands on 11 October 2027, when general support for VCF 8 ends. By that date, every VMware customer has to either migrate to VCF 9 at the new (read: higher) prices and under the new model, or be shown the back door and leave the platform behind.

Not deciding is also a decision

Big decisions like this get postponed fast. Or, in the alternative: you do not decide, and you take the hit. I understand the reflex. Migrations are complex. Infrastructure is critical. You do not want to take risks with production environments. And maybe you are thinking Broadcom will course-correct once the pressure builds. I do not want to give you false hope. By now there is plenty of evidence that Broadcom has no intention of changing course. The messaging is consistent, prices have not come down, and contract negotiations follow a tight, inflexible script.

More importantly, the migration window shrinks every month. A phased, carefully prepared migration of enterprise workloads takes two to three years in practice. If you only start evaluating in 2026, you have almost no room for a calm, controlled execution. The result of waiting too long is not that you end up with more options. It is that you are forced to choose between an expensive rushed migration and an extension with Broadcom at prices you do not actually want to pay. Everyone wins, except the end customer.

And if you are going to migrate anyway, why not move to another on-premises hypervisor? It might look like the most logical step. Nutanix, Proxmox, Microsoft Hyper-V: there are alternatives that keep the virtualization layer intact.

My answer is a nuanced one. For certain workloads with strict data-residency requirements or specific latency constraints, on-premises can remain relevant. But for most companies, switching to another hypervisor is only a stopgap. You solve the price increase, but you keep working with the same operational model. You still manage hardware, license renewals, capacity planning, and the staffing overhead that comes with all of it. On top of that, you trade one vendor dependency for another.

Staying on-premises carries a second problem beyond the licensing model. Hardware is becoming a scarce commodity, and so is datacenter floor space. Prices are going through the roof, and supply is no longer guaranteed.

AWS offers something structurally different: the option to move away from the virtualization layer over time. And getting there is no longer a leap of faith. If you want the smallest possible change on day one, Amazon Elastic VMware Service (Amazon EVS) runs VMware Cloud Foundation directly inside an Amazon VPC in your own AWS account, so the same vSphere, vSAN and NSX stack your team already operates lands on AWS without a re-architecture. If you would rather leave the hypervisor behind right away, AWS Transform MGN (formerly AWS Application Migration Service) replicates your virtual machines block by block and cuts them over to Amazon EC2 with minimal downtime, while AWS Transform for VMware automates the unglamorous parts: discovery, dependency mapping, network conversion, and right-sizing the target instances. The two paths trade off differently. Amazon EVS keeps your VMware stack intact, and with it the VMware licensing, but moves it off your own hardware and onto AWS as the fastest possible landing. The MGN route leaves the hypervisor, and the VMware license, behind outright. Either way your teams keep their existing way of working and do not have to relearn everything on day one.

That is the floor, not the ceiling. Once a workload runs on AWS you can modernize it on its own timeline, and only where the business case justifies it: move a self-managed database onto Amazon RDS or Amazon Aurora, lift a tier of servers into containers on Amazon ECS or Amazon EKS, replace a scheduled job with an AWS Lambda function, and reach for managed AI through Amazon Bedrock. None of that is realistic to run well on-premises, or it is simply too expensive to operate yourself. A like-for-like hypervisor swap does not get you here: it can lower the licensing bill, but the operational model and the eventual modernization are left untouched. Moving to AWS is the option where the immediate fix and the longer-term path share one destination.

We have been doing this at Cloudar for 12 years, and a lot of those conversations reveal the same pattern. At some point an organization made a sound technology choice. And today they find that the choice is holding them in a situation they can no longer defend, or no longer want to. VMware was an excellent choice for years. It was stable, well documented, broadly supported. But the lesson of the Broadcom acquisition is that vendor lock-in is not an abstract technical concern. It is a concrete business risk that, sometimes only after ten or fifteen years, shows up as something you simply have no alternative to.

Moving to AWS does not make that problem disappear entirely, of course. Every major cloud provider has its own ecosystem and its own logic. But the nature of the dependency changes fundamentally. In the cloud you pay for what you use, and you can decide workload by workload how and where you run it. The technical architecture of cloud-native services (open standards, open containers, open APIs) lets you switch when you want. That is structurally different from proprietary hypervisor software with a binary licensing logic. It lets you design with a solid exit scenario built in from the start.

Start with insight, then migrate in phases

Migrations rarely fail on the technology. They fail through a lack of preparation, unclear priorities, and too little attention to the human side of the process. The first step every organization should take is insight: which workloads are you running, what are the dependencies, and what is the real cost of your current VMware installation versus the alternatives? Only once that is clear can you make a rational decision. The tooling to get there has matured: AWS Transform for VMware can inventory a vSphere estate and map its dependencies automatically, and AWS Migration Hub tracks the moves once they start. A Migration Readiness Assessment that used to take months is now achievable in a few weeks.

This is where AWS has invested most visibly. AWS Transform, its agentic migration service, puts AI agents on the parts of a migration that used to eat months of consultant time: discovery, dependency mapping, wave planning, and network conversion, with the actual rehost driven through AWS Transform MGN. It is not VMware-only either; the same agents cover Windows and .NET modernization and mainframe workloads. AWS reports discovery that once took a quarter compressing to about a week, and landing-zone networking provisioned up to 70 percent faster. None of that removes the need to start early. It does mean the preparation that scared you off a year or two ago is no longer the bottleneck it was.

AWS can help fund a lot of this work through the Migration Acceleration Program (MAP). The assessment phase produces a workload inventory, a dependency map, and a costed business case, all of which are yours to keep, whichever direction you choose afterwards. For projects with a strong enough case, MAP can also offset a meaningful share of the migration cost itself. A migration partner runs the assessment and unlocks that funding on your behalf, which is the role we play at Cloudar.

The approach we recommend is phased. Start with the most portable workloads on Amazon EC2, which immediately eliminates the VMware license cost, then replatform workload by workload to AWS-native services as the business case justifies it. And in the meantime, put all new VMware deployments on ice. Every new workload you still put on VMware today is a workload you will have to migrate again later.

What I want to leave you with is this. The best migrations are the ones you carry out when you have the time and the space to do them well. You still have that time and space now, but the clock is ticking. As I write this, there are 467 days left until 11 October 2027. That may sound like a lot…

The post Leaving VMware is a question of timing appeared first on Cloudar.

That is the uncomfortable part of putting an LLM-powered agent into production: you inherit a dependency that never shows up on the architecture diagram. Someone else’s model has to stay reachable for your system to do anything at all. Usually the ways it fails are mundane. The model gets throttled the week you need it most, or deprecated on the vendor’s timeline rather than yours, or it simply has a bad afternoon while your incident volume spikes. June was the reminder that it can also be a regulator drawing a line. Either way, the day it happens, your “autonomous” system is exactly as autonomous as a 500 error.

We had been building an operations agent that investigates tickets and reasons over live infrastructure, and we had already decided not to hard-wire it to a single model. The June suspension is what turned that from a prudent hedge into an obvious one, and it is why we are writing this up now. The agent is genuinely useful, which is the problem: the more people rely on it, the less acceptable “the model is unavailable right now” becomes as an answer. This post is how we think about that availability problem, why we landed on Amazon Bedrock as the foundation, and (more importantly) the things we got wrong on the way, because the interesting lessons are in the pitfalls, not the happy path.

Two ways to stop betting the business on one model

There are really only two structural answers to “what happens when my model is gone”:

• Configure fallbacks. Have more than one model the agent can run on, and fail over when the primary is unavailable.
• Run your own model. Remove the third-party API from the critical path entirely, so availability is something you control rather than something you subscribe to.

Both are sound. Both are also more subtle than they sound, and the subtlety is the whole point of this article. Neither is “set a second model ID and you’re done.”

The reason we built on Amazon Bedrock is that it makes both strategies reachable from one place. Through a single AWS IAM surface, one set of credentials, one regional endpoint, and one billing path, Bedrock gives you access to a large catalogue of foundation models from multiple providers. Via Amazon Bedrock Custom Model Import you can bring your own open-weight models, and Amazon Bedrock Marketplace adds a catalogue of others to deploy. You can layer Amazon Bedrock Guardrails across all of them as a provider-independent safety control, and you keep your data inside your chosen AWS Region. For a European services partner like us, whose customers are specific about where their data is processed, Region control often settles the whole approach before model quality even enters the conversation.

So far, so much like a Bedrock landing page. Here is where it got real for us.

Pitfall 1: “swap the model ID” is an access abstraction, not an application one

The single most useful mental model we developed is this distinction. Bedrock abstracts access and transport: one credential, one API, one bill, to reach many models. It does not abstract the request and response shape your application actually depends on.

When you start, you almost certainly reach for a provider’s own SDK or the request format of whichever model you adopted first. That code grows roots. Your agent loop parses the specific content-block shape that model returns: the way tool calls are represented, the field names, the IDs. Your retry logic, your streaming handling, your token accounting all quietly assume one family’s conventions. The moment you point that code at a different model family, the transport works perfectly and the parsing falls apart, because you didn’t insert a model-agnostic layer. You inserted one-vendor-on-Bedrock, which borrows Bedrock’s plumbing but speaks only one dialect.

Amazon Bedrock does offer a genuinely cross-model interface, the Converse API, which normalises messages and tool configuration into a common shape across many models. Most current foundation models on Bedrock are reachable through it, so adopting Converse from day one avoids a lot of this pain. The catch is at the edges: you trade away some of the richer, provider-specific surface, and a few models still expose their newest capabilities only through their own API shapes. A fully general agent can therefore end up maintaining more than one transport path anyway, which is exactly the situation the next point is about.

The lesson that generalises: build a thin internal seam early. Define one interface that your agent talks to, pick one canonical shape for messages and tool calls, and put each model family behind an adapter that translates its wire format to and from that shape. Concretely, the boundary is about this small:

# one interface the agent depends on; one adapter per model family behind it
class ModelClient(Protocol):
    async def respond(self, messages: list[Block], tools: list[Tool]) -> list[Block]: ...

# AnthropicClient, ConverseClient, ... each satisfy this and own the
# translation between their provider's wire format and the canonical Block.
def make_client(model_id: str) -> ModelClient: ...  # fail-closed: unknown id raises

Your dispatch loop only ever sees the canonical block, never a vendor payload. Make the factory fail-closed: an unrecognised model ID should raise, never silently route to a “best guess.” Fallback is only safe if the fallback path is one you’ve explicitly built and tested, not one your code stumbles into.

This is also why a framework like LangChain or LiteLLM is not a shortcut past the problem. It hands you a ready-made version of that seam across providers, which is genuinely useful, but it abstracts the wire format, not the behaviour. The per-model prompt sensitivity, the tool-calling quirks, the caching mechanics: those leak straight through any unified interface, yours or off-the-shelf.

Pitfall 2: models are not drop-in equivalents, even at equal “quality”

The second hard lesson is that two models can both be excellent and still not be interchangeable in your harness.

Concrete example: provider-specific prompt caching. The cost and latency model of an agent that re-sends a large tool-and-context preamble every turn depends heavily on prompt caching, and the way you mark cacheable spans (and even how many cache breakpoints you are allowed) is vendor-specific. Switch families and your carefully tuned caching strategy simply does not apply; your costs and latency move, sometimes sharply.

Another: model-version quirks. We found a specific model version would occasionally malform its tool calls in a way we had to detect and repair in the dispatch loop. That repair is correct for that version and meaningless for every other model. Tool-calling reliability, instruction-following under pressure, willingness to say “I don’t know” instead of fabricating: these vary enormously between models and are exactly the behaviours an agent lives or dies by.

So “best way to use a model” is real, and it is per-model: the prompt that gets the best out of one model is not the prompt that gets the best out of another, and the safety posture that one model respects, another ignores. A fallback model isn’t a spare tyre of the same size; it’s a different vehicle that happens to drive on the same roads. Treat the migration to it as a real piece of engineering, scoped and tested ahead of time, so that on the day you actually need it you are flipping a switch you have already proven.

Pitfall 3: a fallback ladder is also a cost ladder

The third consideration bites only after you have shipped: the model you fail over to has a different price, and the Region you are obliged to run it in has a different price again. On Bedrock these are two separate effects worth keeping straight. Token pricing varies widely by family, often by an order of magnitude between a frontier model and a lighter open-weight one, which is visible on the public Bedrock pricing page. Separately, Cross-Region inference itself does not add a surcharge: a request is billed at the inference profile’s published rate, which for current AWS profiles matches the on-demand rate of that profile’s primary Region. What moves the number is which profile you are obliged to use. The EU inference profile that keeps data in-region can sit above the cheapest on-demand Region for the same model. In our own cost modelling we carry roughly a 10% uplift on the EU inference-profile routes for our primary family against the equivalent US on-demand rate, and we treat that as the standing price of residency.

So a fallback ladder is also a cost ladder, and the two do not move together. Failing over to a cheaper open-weight model can save money while costing you quality; failing over to a residency-compliant route can cost more for the same model. Work both deltas out in advance, so a failover event doesn’t arrive as a billing surprise stacked on top of an incident.

Where Bedrock genuinely shines: cheap, isolated, side-by-side evaluation

Here is the flip side of all that subtlety: because every model lives behind the same Bedrock access surface, comparing them becomes an infrastructure problem you already know how to solve, not a procurement project per vendor.

We stood up a second, isolated runtime (same agent code, separate deployment, separate logs, separate metrics namespace) whose only job is to run candidate models against hard, representative tasks without touching production. A few design choices made this evaluation trustworthy, and they generalise well:

• Isolate it at the infrastructure level, not by convention. A separate runtime, image tag, log group and metrics namespace mean eval traffic can never pollute production dashboards or alerts, and a candidate model can never accidentally take a real action. Make the isolation fail-closed: if the eval deployment is missing its explicit configuration, it should refuse to deploy rather than fall back to production settings.
• Grade blind. If the evaluation environment can read the “right answer” (a human’s resolution notes, a linked root-cause record), a weaker model can look strong by quietly reading the answer key. Strip those inputs so you are measuring reasoning, not retrieval of the solution.
• Run a harness-fit probe before you blame the model. When a candidate underperforms, the natural reaction is “our prompt isn’t tuned for it.” So test that hypothesis directly: harden the prompt specifically for the candidate and re-measure. Our most valuable single finding came from this: the gap between our primary model and the alternatives was mostly model-intrinsic, not a prompt artefact. That told us the seam was worth keeping for break-glass resilience, but that switching the default wasn’t justified yet. You only learn that by measuring.

A safety note that bears repeating, because it surprised us: a “dry-run” flag that suppresses one kind of side effect doesn’t suppress all of them. In our case, suppressing the agent’s writes did not suppress its reads against live infrastructure. If a candidate model can call tools, those calls execute for real during evaluation. The durable backstop is least-privilege, read-only credentials at the boundary, not a flag in your application code. Defence in depth applies to your evaluation environment too.

Running your own model: removing the API from the critical path

Configuring fallbacks hedges against one model being unavailable. Running your own hedges against a different risk: not wanting your core workflow to depend on a third-party inference API at all, whether for sovereignty, predictable capacity, or a model fine-tuned on your own domain. The point of doing it on Bedrock is that the operational surface barely changes when the weights become yours: the same IAM controls and the same API, with Guardrails layered on where the model architecture supports them. Amazon Bedrock Custom Model Import brings supported open-weight architectures behind that surface; Amazon Bedrock Marketplace widens the catalogue; and Provisioned Throughput reserves dedicated capacity for steady, latency-sensitive load. Because the surface stays the same, a single seam can mix managed and self-hosted models on the same ladder.

The honest caveats are real but different from classic self-hosting. With Custom Model Import the serving and autoscaling stay AWS-managed (billed by Custom Model Units, with cold-start latency on an idle model), so what you take on is the cost model, the supported-architecture limits, and a quality bar an open-weight model may not clear for your task, not server ops. You only own capacity planning and scaling if you go all the way to your own Amazon SageMaker or EC2 endpoints, outside Bedrock. For most teams the right posture is a hybrid:

• Primary: a strong managed model. Your default. The one you have evaluated hardest and trust unattended.
• Fallback: a tested alternative, break-glass. Already proven through the seam on a normal day, not discovered during an outage.
• Self-hosted: for workloads where control wins. Reserved for cases where sovereignty or capacity genuinely outweighs the operational cost.

What we’d tell our past selves

• Build the seam before you need it. One internal interface, one adapter per model family, fail-closed routing. Retrofitting this under outage pressure is miserable.
• Treat “switch to the fallback” as engineering, not configuration. Prompts, caching, tool-calling quirks, and safety posture are all per-model. Prove the fallback works on a normal day.
• Default to your best model; keep the alternative warm. The point of the seam often isn’t to leave your strongest model; it’s resilience and the option to re-evaluate as the field moves.
• Make evaluation a first-class, isolated environment. Blind grading and a harness-fit probe will tell you whether your problem is the model or your prompt, saving you from both over-engineering and false economy.
• Put the real safety control at the boundary. Read-only, least-privilege credentials and Guardrails protect you regardless of which model is behind the seam, including during evaluation.

Those five are tactics. The shift underneath them is the real payoff. Amazon Bedrock did not make the model-specific subtlety disappear, and nothing will. What it changed is where the subtlety lives: behind one access surface, one security model, and one bill that we own, instead of scattered across vendor relationships we could only hope held. “Keep the agent running when a model goes dark” stopped being a procurement question and became an architecture decision.

Written at Cloudar, an AWS Premier Tier Services Partner. The lessons here come from production experience building AI-assisted operations tooling on AWS.

The post When the model goes dark: keeping your AI agent available on Amazon Bedrock appeared first on Cloudar.

The problem? For most organisations, it delivered exactly what you’d expect when you relocate an existing environment to a new address: the same bottlenecks, the same inefficiencies, the same complexity. Just with a monthly invoice attached. Fast forward to today.

The invoice as a symptom

The appeal of lift & shift is understandable. No fundamental architecture changes. Limited impact on running applications. Minimal business disruption. A fast time-to-cloud that was easy to sell internally. For a specific type of workload – end-of-life systems or legacy environments you’rewinding down in the short term – it’s still a legitimate tactic today. Especially if it lets you shut down an entire data centre. But as a migration strategy, it’s postponement, not a real solution.

On-prem systems were designed for a world of fixed capacity. Servers run continuously whether the load justifies it or not. Redundancy lives in hardware, not in design. The economic logic of cloud is precisely the opposite: you pay for what you use and scale to what you need. That partnership between IT and Finance has a name: FinOps. The discipline that ties cloud spending to actual business value. Bringing an on-prem architecture to the cloud unchanged means importing the inefficiencies of the old model into an environment that was never built for them. And paying for that continuously.

In practice, this means: virtual machines running 24/7 when the workload doesn’t require it (idle resources), storage not tiered by access frequency, and applications moving data unnecessarily between regions or availability zones, each generating data transfer costs. Without FinOpsdiscipline, no one in the organisation has a clear picture of what the cloud actually costs per application, per team, or per business unit.

The result is an invoice that runs higher than the data centre you left, with less flexibility than you expected. Not because cloud is too expensive. But because you never made the shift from ‘infrastructure in the cloud’ to ‘cloud-native architecture with cost accountability’.On-prem doesn’t fix that. It just moves the problem and adds five-to-seven-year hardware depreciation cycles to the books. The costs become slightly less visible, but you’ll feel them regardless. Especially as hardware prices keep climbing due to supply constraints.

KarmAI

For years, the architectural debt of lift & shift was a slow-burning problem. Systems ran, bills were higher than expected, but business carried on. AI has changed that. Not gradually, but abruptly.

AI workloads require infrastructure that is fundamentally different from what classic enterprise applications need. Data must be accessible easily and at scale, not locked in legacy storage structures that were once migrated one-to-one. Integration with managed services like Amazon Bedrockworks better when your environment is built on cloud-native standards. AI workloads also have a volatile cost profile: a training job or inference spike can consume more in hours than a classic application does in a month. Without FinOps mechanisms to monitor, cap, and allocate those spikes, you lose all control over your AI budget.

But that’s only the short-term pain. Because organisations that did lift & shift also migrated their data mess along with everything else. No proper classification, no clear ownership, no consistent structure. For classic applications, that was annoying but manageable. For AI, it’s fatal. You can’tfine-tune a language model on unstructured data scattered across poorly managed cloud systems. You can’t build a RAG architecture if you don’t know where your data lives or what its quality is.

Organisations that are serious about AI are being forced to revisit their cloud architecture anyway. What once looked like a technical problem has become a strategic delay… right at the moment AI is starting to make the competitive difference. And organisations that now decide to return to on-prem entirely will only widen that gap.

On-prem is capitulation

Organisations considering cloud repatriation today are asking themselves the wrong question. Because the discussion isn’t really about cloud versus on-prem. It’s about focus and resource allocation: what does your organisation actually need, and are you capable of managing it well?

Is it five to midnight for some organisations? Yes. But for those who commit to a cloud-native approach, it will become clear that cloud was the right choice all along. And that anyone thinking about repatriation today will find there’s still a great deal of cloud potential left untapped.

If the cloud hasn’t delivered on its original promises, it’s usually because the architecture never became truly cloud-native. Data that was never properly structured. FinOps discipline that was never built in: no centralised cost reporting, no shared accountability between IT and business, no culture where teams think about the cost of what they build and run. And a mindset that carried on-prem patterns into an environment where they don’t belong.

You don’t solve those problems by switching environments. You solve them by acknowledging them and addressing them. And that can absolutely be done in the cloud… if you’re willing to do it differently this time.

The post Back to on-prem? appeared first on Cloudar.

Somewhere in Europe, a tram is running right now with a bearing fault that will cause a breakdown in eleven days. The onboard sensor has been registering it for weeks. But no one caught it. Why? Because no one was looking in the right way.

Modern vehicles are loaded with sensors. Vibration, temperature, brake pressure, power consumption: every detail is measured. But a sensor is just a sense organ, not a brain. Local alarms are reactive: they tell you what has already gone wrong. The real shift happens when you stop looking at data vehicle by vehicle, and start looking across an entire fleet. When hundreds of vehicles stream their telemetry to a central cloud platform, something fundamentally different emerges: fleet-level intelligence.

AWS provides a proven foundation for exactly this. Through AWS IoT Core, sensor data from thousands of vehicles – whether trains, trams, or buses, at any scale – flows in real time to a central platform. And what you see from there changes the nature of your decisions entirely.

The platform doesn’t just see that vehicle 47 is showing an unusual vibration. It sees that every vehicle travelling a particular route today showed the same anomaly. And from that, it draws the right conclusion: the problem isn’t the train. It’s the track. That’s the difference between raising a maintenance ticket and preventing an incident.

Cost vs ROI

Traditional preventive maintenance replaced parts on fixed schedules: expensive, inefficient, and often unnecessary. Cloud-based condition monitoring inverts that logic. You maintain what needs maintaining, exactly when it needs it.

For a COO, that means higher fleet availability and fewer unplanned disruptions. For a CFO, it means maintenance costs that move with reality rather than with a calendar. For a CEO, it means a direct, structural impact on the reliability promise made to passengers.

The cloud also democratises this capability. Large national rail operators have the scale to build their own data infrastructure. Regional transit authorities typically don’t. Through AWS, even a regional bus operator gains access to enterprise-grade analytical computing power, without the capital investment in hardware or specialist data teams.

But let’s be direct: data infrastructure alone solves nothing. The most common failure we see in transport organisations is not a lack of data. It’s the opposite: an abundance of data that no one actively uses. Vast amounts of operational information gets stored and never converted into decisions. A cloud analysis that identifies an imminent fault has zero value if getting that insight to the maintenance team takes three days of bureaucracy.

This is precisely where the role of the CTO and CIO extends beyond architecture choices. Technology can only prove its value if the organisation around it is built to act on insights. Technology and organisation must evolve together.

Public trust as a strategic objective

Public transport stands at a historic inflection point. The mobility transition asks people to swap their car for a train, tram, or bus. But they’ll only do that if they trust the system. Safety and punctuality are not operational parameters. They are the pillars on which that trust rests and on which the legitimacy of your organisation as a public service provider depends.

That trust isn’t earned once. It’s built daily, or quietly eroded. Every delay that could have been prevented, every breakdown that feels avoidable, every passenger who gives up and goes back to the car: these are small fractures in a foundation that took generations to build.

The technology available to us now offers something that was unthinkable not long ago: the ability to see those fractures before they form. An organisation that understands its fleet as a learning system – one that recognises patterns, flags anomalies, and gives context to raw data – is an organisation that can make a promise to its passengers and actually keep it.

That is ultimately what this is about. Not technology as an end in itself, but what it makes possible: a public transport system so reliable that choosing the train or the bus becomes second nature. Not a conscious trade-off anymore, but a habit. And habit is the highest form of trust.

The post Tram, train, bus… the future is fleet-level intelligence appeared first on Cloudar.

A challenging process

The recognition is the result of an intensive approval process. While global players recently announced the same status, Cloudar is the first partner with a local Benelux presence to have achieved this designation. To qualify, a partner must be able to demonstrate proven revenue and a substantial Anthropic-related pipeline — a threshold that only a handful of AWS partners worldwide manage to meet.

In concrete terms, this means that Cloudar is now the only Benelux partner able to:

• Deliver enterprise seats for Anthropic
• Fully onboard customers onto the latest Anthropic models via AWS Bedrock
• Build AI solutions based on models such as Claude Code, directly on AWS infrastructure

Since the AWS policy change of October 2025, access to the latest Claude models via Bedrock requires the managing AWS partner to be officially recognised by Anthropic. Customers working with an unrecognised partner simply cannot activate these models, regardless of their own intent or budget. As a result, large organisations in the Benelux have been left out in the cold for several months. Cloudar’s recognition now puts an end to that.

Strategic advantage in a competitive market

“This partnership is no coincidence. It is the result of years of deliberate choices. From the very beginning, we committed to AWS as our sole platform and to AI as our biggest growth pillar. The Anthropic Authorized Reseller status confirms we are on the right track. For our customers, it means they can start working today with the most advanced AI models on the market, supported by a local team that guides them through the entire journey — from architecture to governance to optimisation,” says Senne Vaeyens, Co-Founder and Managing Partner at Cloudar.

As the first local Benelux partner with this recognition, Cloudar can now offer organisations in the region a complete answer to their AI challenges, within the familiar AWS environment they already use. Whether it concerns a first AI experiment or a production-ready implementation on AWS Bedrock: Benelux customers no longer need to look to international players to get there.

The post Cloudar is first local Benelux Anthropic Authorized Reseller appeared first on Cloudar.