What actually changed

Teams keep building in Lovable exactly as they do today, but the result now lands in a dedicated VPC in your own AWS account: EKS, S3 and Lambda, Aurora PostgreSQL, keys in KMS. Internal systems are reached over VPC peering, setup is a CloudFormation stack your team reviews, updates arrive as signed Helm charts, and the only link back to Lovable is outbound mTLS. A Lovable app becomes a normal AWS workload, and your existing IAM, CloudTrail, SSO and landing zone guardrails apply from day one. Governance is yours, you choose the region, and the infrastructure consumption lands on your own AWS bill.

Why this matters

Vibe coding, not meaning AI-assisted development with tools like Claude Code, already happens in every enterprise. Office workers fix small problems all day with self AI-built automations and quick apps, often outside IT’s view. Shadow AI was born the same way entire businesses once ran on home-grown Excel sheets and Access databases: the business wanted speed and IT could not keep up. With Lovable Deploy on AWS, the speed the business wants and the governance IT wants finally come together.

In my opinion, this is a very strategic move for both Lovable as well as AWS. Lovable gets the enterprise credibility it could never build alone: a secure home inside the customer’s own cloud. AWS gets the business users it never had a direct product for, and turns the shadow AI it was missing into governed workloads on its platform. Together they bridge the gap between the business that wants to build and the IT department that has to answer for it. My expectation is that this release is only the beginning, and I would not be surprised to see further announcements around AWS re:Invent. Although this announcement is really coming from Lovable, and the AWS press release has yet to appear, It fits a broader shift in how AWS talks about delivery: the “forward deployed engineer”, who does not wait for requirements but sits with the business, understands the problem first-hand and ships the solution inside the customer’s own environment. Lovable on AWS is made for that model. The business builds the first version, the forward deployed engineer gives it a production-grade home on AWS, and the distance between the two shrinks from quarters to weeks.

A few caveats.

The current announcement is not perfect yet. Only the app and its data move to AWS. The editor, the AI agent and your chat history stay with Lovable, which regulated companies will want to check first. Currently, It is also a private preview, so not every feature is there yet, and Lovable is still young on security: in April this year a flaw let users see other people’s project data. Your own AWS account makes these apps possible to govern, but it does not govern them for you.

Final toughts

Still, none of the caveats changes my view. This direction is likely the start of much more, and the trend matters more than having everything perfect today. Business teams will increasingly build their own apps and the push to do it on infrastructure you control is there. With Lovable on AWS, those two worlds finally converge. Looking forward to the announcements to come.

The post Lovable on AWS: has enterprise-grade vibe coding been born? appeared first on Cloudar.

Below is our attempt at a complete answer, from what ESC is to how to choose between commercial, sovereign and hybrid. It ends with the most interesting thing AWS has announced about ESC so far: on Saturday 24 October, it will cut ESC off from the AWS global network on purpose.

What the European Sovereign Cloud actually is

ESC became generally available on 14 January 2026 with one Region, eusc-de-east-1 in Brandenburg, Germany, and more than 90 services. Today, AWS’s Capabilities by Region explorer lists 104 services as available there (with, for example, each RDS engine and FSx variant counted separately), and 886 services and features in total. Three things make it more than “another EU Region”.

It is a separate partition. Next to the commercial cloud (aws), AWS already runs separate partitions for China (aws-cn), GovCloud (aws-us-gov) and isolated US classified Regions. ESC adds aws-eusc, with its own IAM, its own AWS Organizations, its own billing in euro, its own console and its own endpoints under amazonaws.eu. ARNs start with arn:aws-eusc:. Existing accounts do not carry over; you open new ones.

It has its own control plane, in the EU. A dedicated Route 53 whose name servers use only European top-level domains, its own EU trust service provider and root certificate authority, and a dedicated European security operations centre. Customer content stays in the EU, and so does customer-created metadata such as roles, permissions, tags and configurations. In exceptional cases, EU-resident ESC staff have independent access to a replica of the source code needed to maintain the services.

It is run by a European company, with European people. ESC operates through German GmbH entities led by EU citizens, with an advisory board of EU citizens that includes two independent members. Day-to-day operations are carried out exclusively by EU residents located in the EU, and AWS is gradually moving to EU citizens only.

AWS plans to invest more than €7.8 billion in Germany through 2040, and backs the governance with a Sovereign Reference Framework (ESC-SRF) in AWS Artifact and a first set of attestations in March 2026: SOC 2 Type 1 and C5 Type 1 reports covering 69 services, plus seven ISO certifications. Type 1 means control design at a point in time, not operating effectiveness over a period; normal for a young cloud, but relevant if your auditor expects Type 2. Sovereign Local Zones in Brussels, Amsterdam and Lisbon were announced at launch and are still listed as announced, without a date. AWS has not announced a second ESC Region yet, but we expect more to follow. Read everything this post says about a single Region as a snapshot, not a permanent property.

What ESC does not change is who ultimately owns it: Amazon.com, Inc. The ESC Addendum commits AWS to redirect government requests to the customer, notify you, and challenge requests that conflict with EU law. It also says AWS will not move your content or customer-created metadata outside the EU “except as instructed by Customer or as necessary to comply with a valid and binding order of a governmental body”. AWS reports that no enterprise or government content stored outside the US has been disclosed to the US government since it started publishing that figure in 2020. Whether that is enough for you is a legal judgement, and one that has not been tested in court. We are not lawyers; put that question to yours.

How it differs from the other hyperscalers’ sovereign clouds

Every major provider now sells something called sovereign, and the word covers very different architectures. At hyperscale, there are two.

Microsoft describes its Sovereign Public Cloud as “built on Microsoft’s global Azure infrastructure with enhanced sovereignty controls, such as Data Guardian, External Key Management, and tamper-evident access logs”. And in fairness, the separate-cloud model is not an AWS invention: Oracle has run its EU Sovereign Cloud as a separate realm since 2023.

Two kinds of offer are left out of this comparison on purpose. Disconnected and air-gapped clouds run a much smaller service set and solve a different problem. Partner clouds, such as Bleu and Delos Cloud on Microsoft technology or S3NS on Google technology, are a different category: a European company runs the hyperscaler’s software on its own, national-scale infrastructure. The catch is scale: capacity limited to what the partner has built, a core service set rather than the full catalogue, and features that arrive only after the licensor’s release cycle and the partner’s own checks. If your requirement is a European-owned operator, that is where to look. If it is hyperscale behind a sovereign boundary, they are not comparable to ESC.

What sets ESC apart is the combination: the same APIs, tooling and engineering organisation as commercial AWS, behind a partition boundary with its own identity, billing, DNS and PKI, run by EU entities. It is a partition, not a setting. That is its biggest strength and, as we will see, the source of most of its cost.

ESC versus Oracle EU Sovereign Cloud

Oracle’s EU Sovereign Cloud is the closest analogue, so it deserves a direct comparison. Both are separate clouds (a partition at AWS, a realm at Oracle) owned and run by EU legal entities, with support and operations restricted to EU residents. The differences are in how far the independence goes, and how much of it is documented.

Where AWS has an advantage. Operational autonomy and independence from global infrastructure are ESC’s strongest differentiators. AWS explicitly documents that ESC has no critical dependencies on infrastructure outside the EU, including the ability to keep operating if connectivity with the global AWS network is interrupted, and it is about to demonstrate that in public (more on that at the end). AWS also documents independent identity management, billing and metering, EU-based trust services and a dedicated security operations centre. Oracle states that its realm is “completely isolated both physically and logically from other Oracle realms”, but its public documentation does not describe separate identity, billing, trust services or a security operations centre at that level of detail. On governance, ESC’s advisory board includes two independent members who are not Amazon employees, a mechanism on top of the EU-incorporated operating subsidiaries. Oracle documents boards of directors made up of European nationals across its seven EU entities, but does not mention independent members.

Where Oracle has an edge. Two regions, Frankfurt and Madrid, against ESC’s one today, which matters if you need disaster recovery without leaving the sovereign cloud. We expect AWS to add ESC Regions over time, but until it does, that gap is real. A realm that Oracle says supports all its commercial services except some. And three years in the market.

The short version: if your requirement is demonstrable operational independence and governance, ESC documents and tests more. If you need disaster recovery without leaving the sovereign cloud today, Oracle is ahead.

What the analyst quadrants do, and do not, tell you

In Gartner’s 2026 Magic Quadrant for Strategic Cloud Platform Services (1 September 2026), AWS is a Leader for the 16th consecutive year and placed highest on Ability to Execute. Google, also a Leader, is placed furthest on Completeness of Vision.

But a Magic Quadrant positions vendors, not partitions. Nobody gets a separate dot for their sovereign offer. The quadrant tells you about the platform and the engineering organisation behind ESC, which counts for a cloud that is nine months old; it does not assess ESC itself. Nor does it tell you how ESC’s catalogue, ecosystem or sovereignty posture compares with Bleu, S3NS or Oracle. Gartner has no Magic Quadrant for sovereign cloud; its Market Guide for Cloud Infrastructure Sovereign Solutions (June 2026) describes that market without ranking it.

The closest thing to a sovereign ranking is ISG’s 2025 Provider Lens for Sovereign Cloud Infrastructure Services (EU). It evaluated 19 providers and named AWS a Leader for the third year in a row, with the highest score on portfolio attractiveness, crediting a “sovereign-by-design architecture that ensures data residency and regional independence”. Note the timing: the report appeared on 9 January 2026, days before ESC became generally available. It reflects AWS’s sovereignty portfolio and roadmap before ESC went live, not ESC as it runs today, which makes it as much an endorsement of the commercial Regions’ sovereignty controls as of ESC.

Not going to ESC? The commercial Regions are not the non-sovereign option

At the ESC launch, AWS itself said that “most customers are able to meet their requirements using one of the six existing AWS Regions in the EU”. There is evidence behind that.

On 22 September 2026, AWS announced that it is the first cloud provider whose services are approved for NATO RESTRICTED use by all NATO member nations. Spain’s National Cryptologic Centre (CCN) evaluated AWS against D32, NATO’s directive for handling NATO RESTRICTED information in public cloud, with AWS’s Trusted Secure Enclave Sensitive Edition as the baseline. Approved services can now be used at that level in any AWS Region located in a NATO member nation. Two caveats keep this honest. It is a pre-assessed baseline that gives Allies an accelerated path, not an accreditation of your system; that is still delegated to a member nation and/or the NATO Communications and Information Agency. And NATO RESTRICTED is NATO’s lowest classification level. One detail for Belgian readers: Frankfurt, Paris, Milan, Spain, Stockholm and London are in NATO member nations. Ireland, home of eu-west-1 and of many Belgian workloads, is not. Keep that in mind when designing your Region strategy.

The commercial Regions also carry the controls of the AWS Digital Sovereignty Pledge: the Nitro System, designed so that AWS operators cannot access customer content on EC2 instances, reviewed by NCC Group and written into the AWS Service Terms; AWS KMS External Key Store, which keeps key material in an external key manager you operate outside AWS (AWS recommends it only where that is an explicit requirement, because if it goes down, so does everything that depends on it); Control Tower data residency controls, including Region deny per organisational unit; and Dedicated Local Zones for single-customer infrastructure where you need it.

So the realistic question is not “sovereign or not sovereign”. It is which risks you need to mitigate, and whether a partition boundary mitigates one that these controls cannot.

Available is not the same as available

This is where most ESC plans go wrong. A service on the ESC list does not mean the service you use in Frankfurt is there, with the features you use.

AWS’s Capabilities by Region data, available in AWS Builder Center and through the AWS MCP servers, shows four states: Available, a directional launch quarter, Planning (“evaluating launch strategy”) and Not Expanding, which AWS defines as “will not launch in region”. For eusc-de-east-1, at the time of writing:

• Planned with a date: Amazon CloudFront (Q4 2026), Amazon Inspector and AWS Shield Advanced (Q1 2027).
• Planning, no date: AWS Application Migration Service. For a migration partner, that one stings: rehosting into ESC today means VM Import/Export, AWS Elastic Disaster Recovery or AWS DMS instead of MGN.
• Not Expanding: Amazon Detective, Amazon Security Lake, AWS CloudHSM, Amazon Textract, Amazon Q Developer and Amazon Elastic VMware Service, among others.

The subtler gap is inside services that are available. DynamoDB is there; Global Tables are Not Expanding. Route 53 is there; domain registration is at Planning. S3 is there; Multi-Region Access Points are at Planning. EC2 is there; Reserved Instances are not, so EC2 commitments go through Savings Plans. Some of this follows logically from a single-Region partition and should change once ESC gets more Regions. Until then, it is a gap for an architecture designed in Frankfurt.

Bedrock: the service is there, most of the models are not

Amazon Bedrock is available in ESC. Its model catalogue, at the time of writing, is Amazon Nova Pro, Amazon Nova Lite and three Gemma 4 variants served through the OpenAI-compatible bedrock-mantle endpoint. There are no Anthropic Claude models. Nova 2 Lite and open-weight models from Mistral AI and OpenAI were announced in May for “the coming months” and have not arrived. Guardrails is available; Knowledge Bases, Agents and AgentCore are at Planning.

The Gemma 4 launch in September is the most practical AI building block in ESC today, and AWS’s walkthrough is worth reading. Three things stand out:

• Open weights. Gemma 4 is released under Apache 2.0, so you can evaluate, benchmark and fine-tune the model yourself, without depending on a model provider’s roadmap. For a sovereignty discussion, that is an argument in its own right.
• How inference data is handled. AWS describes a zero operator access model, in which “no service operators can access model input or output during inference”, and zero data retention by default (with limited retention for abuse detection on some models). Every request stays in-Region in eusc-de-east-1.
• An OpenAI-compatible endpoint. Existing OpenAI SDK code moves over by changing the base URL and the key:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://bedrock-mantle.eusc-de-east-1.api.amazonwebservices.eu/v1",
    api_key=os.environ["AWS_BEARER_TOKEN_BEDROCK"],  # short-term Bedrock API key, valid up to 12 hours
)

response = client.responses.create(
    model="google.gemma-4-31b-it",
    input="Summarise this incident report in three bullet points.",
    store=False,
)
print(response.output_text)

The three variants cover the usual trade-offs: the 31B dense model for reasoning and coding (256K token context), the 26B-A4B mixture-of-experts model (3.8 billion active parameters per token) for cost-sensitive, high-throughput work, and the compact E2B for latency-sensitive or multimodal classification (128K context).

AWS has not said why, but part of the reason is structural. In Frankfurt, a model like Claude Sonnet 5.5 is not served in-Region at all: it runs through EU geographic cross-Region inference, which spreads requests over the EU Regions, or through global inference. ESC is one Region without cross-Region inference, so every model needs dedicated capacity in Brandenburg before it can appear. The catalogue will grow, but expect it to trail the commercial EU Regions at least until ESC has more than one Region. If your AI roadmap depends on frontier models, that alone may decide where those workloads live (see also When the model goes dark).

The practical rule: write your requirements at feature level, check them against Capabilities by Region and the per-service difference pages of the ESC User Guide, then test. The two sources do not always agree, which tells you how fast this is moving.

The ecosystem is not there yet

ESC has its own AWS Marketplace, with more than 165 solutions by May 2026, but it is a separate catalogue: only SaaS and AMI products are supported, and a SaaS listing must be deployable in ESC and keep its data there. Some vendors have shipped: AWS reports SAP Cloud ERP Private as generally available on ESC, and Sumo Logic launched its security operations platform there in June. Many others have announced intent and not shipped. At the time of writing:

• Snowflake, announced in 2025 as preparing for ESC, does not list an ESC Region on its supported-regions page.
• MongoDB said in 2025 it was preparing for ESC. The Atlas request for eusc-de-east-1 is at “Future Consideration”, with MongoDB saying in February that it is actively evaluating support.
• Trend Micro has announced plans for Vision One on ESC, without a date.
• Datadog’s AWS integration API accepts the partitions aws, aws-cn and aws-us-gov, not aws-eusc.

That is not a criticism of those vendors: building a SaaS control plane in a new partition is real work, and waiting for demand is a reasonable decision. But this gap matters more than most service gaps, for a reason that is easy to miss: your toolchain is inside your sovereignty boundary. ESC keeps your content and your metadata in the EU under EU operations. An observability, CSPM, backup or ITSM tool that reads your ESC accounts from a control plane outside the EU exports exactly what ESC was built to keep in. Before you design an ESC landing zone, list every tool that holds an IAM role in your accounts and check where each one runs.

Commercial, ESC or hybrid: how to decide

Start with the requirement, not the product. Three questions do most of the work.

1. Who requires sovereignty, and what exactly do they require? “Customer content stays in the EU” is met by any EU Region. “Only EU-resident staff operate the systems”, “customer-created metadata stays in the EU” or “the service keeps running when cut off from non-EU infrastructure” are where ESC earns its place. “A European-owned operator” is met by neither ESC nor any other US-parented option.
2. Does the workload fit inside today’s ESC? Services, features, models and every SaaS tool in the path.
3. Which data actually needs it? Data classification, not the application map, should draw the line.

The answer usually lands in one of three shapes.

AWS’s architecture guidance adds a fourth pattern: ESC as a sovereign failover target, with production in a commercial Region and backups, a pilot light or a warm standby in ESC. If your concern is geopolitical or legal disruption rather than day-to-day operation, backups or a tested pilot light are often the cheapest way to buy that exit option.

Whatever the shape, one rule decides whether hybrid works: the boundary has to follow the data. If the data you put in ESC gets copied into commercial for a dashboard, a model prompt or a support ticket, you have paid for the partition and kept the risk.

Hybrid means two clouds, and you pay for both

A hybrid estate is not one AWS environment with an extra Region. It is two environments that share an API style. AWS’s ESC landing zone guidance is explicit: a role in aws cannot assume a role in aws-eusc (or the reverse), and VPC peering, Transit Gateway, AWS RAM, S3 replication, ECR replication, AMI copy and VPC endpoints do not cross the boundary. In practice that means:

• Two organisations, two landing zones, each with its own management account, guardrails, logging and security services.
• Identity configured twice: a second IAM Identity Center instance federated to the same corporate identity provider, and CI/CD with one OIDC trust per partition, or a deployment plane inside ESC.
• Networking through the front door: TLS over the internet, Site-to-Site VPN or a separate Direct Connect connection. A commercial Direct Connect gateway cannot be extended into ESC.
• A separate supply chain: images and AMIs rebuilt or re-signed inside ESC rather than replicated, and certificates per partition.
• Infrastructure as code that knows about partitions. Anything that hardcodes arn:aws: breaks. Cheap to fix early, expensive to fix late:

# CloudFormation: let the template resolve the partition
Resource: !Sub "arn:${AWS::Partition}:s3:::${BucketName}/*"

# Terraform: same idea
data "aws_partition" "current" {}

locals {
  bucket_arn = "arn:${data.aws_partition.current.partition}:s3:::${var.bucket_name}"
}

Service endpoints move to amazonaws.eu, but IAM service principals such as lambda.amazonaws.com stay on amazonaws.com in both partitions.

Then there is the bill, where three costs stack up.

The unit price. ESC list prices are set in euro, at a figure slightly below the dollar price in Frankfurt. Lambda in ESC costs €0.0000164477 per GB-second against a commercial list price of $0.0000166667 in Frankfurt: about 1.3% lower as a number, but in a stronger currency. In dollar terms the premium is the exchange rate times 0.987, minus one: around 8.5% at 1.10 dollars per euro, around 18% at 1.20. A tecRacer comparison at launch, against Frankfurt, found roughly 15% across S3, FSx, EC2, Lambda, RDS and DynamoDB. Compared with Ireland, EC2 comes out higher, because Ireland is cheaper than Frankfurt to begin with. The flip side: commercial Regions can invoice in euro, but their prices are set in dollars and converted at the exchange rate of the invoice date. ESC list prices are set in euro, so the bill carries no currency risk, which some finance teams will value.

The commitment model. No EC2 Reserved Instances; EC2 commitments go through Savings Plans. Check the commitment options per service before you port an RI-based FinOps practice.

The duplication. A second landing zone, a second security tooling stack, a second identity configuration, a support plan in the second partition, data between partitions billed as data transfer out on the sending side, and the people who run it all. For a small ESC footprint, this fixed overhead easily exceeds the premium on the workload itself.

Which means hybrid is not automatically the cheaper option. When the workloads that could stay in commercial are small, or tightly coupled to the ones that must move, running two clouds and the integration between them can cost more than putting everything in ESC and paying the premium on the lot. Run both numbers before you decide to split.

ESC costs a little more per unit and a lot more per boundary. Put as little behind the boundary as your requirement allows, unless the boundary itself costs more than the premium you are trying to avoid.

Where Cloudar fits

This is the part where we talk about ourselves, so read it with that in mind. Cloudar is an ESC launch partner, holds the AWS Digital Sovereignty Competency, delivers Partner-Led Support in the AWS European Sovereign Cloud, and has built landing zones in the aws-eusc partition. That work has taught us that the hard part is rarely the ESC technology. It is keeping the moving parts consistent, so we have organised our work around the four questions customers actually ask:

Start with the Sovereignty Assessment. It is the step most organisations skip, and it decides whether the other three are needed at all. For many organisations the answer will be to stay in the commercial Regions with the right controls enforced. That is a valid outcome, and we will tell you so.

Saturday 24 October: AWS pulls the cable

Claims about operational independence are easy to write and hard to verify, so AWS is going to test one in public. On Saturday 24 October 2026, for several hours, ESC will run without its connection to the AWS Global Network backbone, the private network that normally carries authorised operational data between AWS locations. A dedicated system that handles limited, controlled transfers of operational data will be fully disabled, and traffic moves to ESC’s own internet connectivity from European ISPs. The exercise was called for by ESC’s managing directors and is run by a team made up entirely of EU residents.

What to expect. AWS says service availability inside ESC, other Regions and Direct Connect are not affected, but there may be brief connectivity disruptions at the start and end while routes converge on other networks. If you run cross-partition integrations over the internet or VPN, keep an eye on your monitoring that weekend.

What it proves. AWS designed the exercise to be consistent with the Commission’s Cloud Sovereignty Framework and BSI’s C3A, and will share an update with regulators and customers afterwards. That is the kind of evidence those frameworks ask for, and more than a policy document can offer.

Which brings us back to where we started. ESC is not the answer to every sovereignty question, and it is not just a label either. It is a partition: real operational separation, real gaps, real costs. The question is not whether ESC is sovereign enough. It is which of your data needs a partition, and whether you are prepared to run two clouds to give it one.

Service, feature and model availability in this post was checked against AWS Capabilities by Region, the ESC User Guide and the Amazon Bedrock model documentation on 16 October 2026. ESC is changing quickly; check before you plan.

Gartner, Magic Quadrant for Strategic Cloud Platform Services, 1 September 2026. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organisation and should not be construed as statements of fact. GARTNER and MAGIC QUADRANT are registered trademarks of Gartner, Inc. and/or its affiliates.

ISG Provider Lens, Multi Public Cloud Services, Sovereign Cloud Infrastructure Services (EU), 2025. ISG does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings. ISG research publications consist of the opinions of ISG’s research organisation and should not be construed as statements of fact.

The post The AWS European Sovereign Cloud is a partition, not a setting. Here is how to decide whether you need it. appeared first on Cloudar.

Today, a company can acquire Claude in four ways: directly from Anthropic, via Amazon Bedrock, via Claude Platform on AWS, or via AWS Marketplace. Each route affects where data is processed and how billing works. On top of that, token usage from agentic tools such as Claude Code can quickly add up, with no cap. Many organizations also run into a more practical problem: they simply can’t purchase Claude today, because they lack a suitable master agreement or vendor relationship with Anthropic, or because something as basic as paying by credit card doesn’t fit their procurement process. In regulated organizations, adoption therefore gets stuck on a few questions: where does our data go, what will this cost, and how do we actually buy this?

From tool to managed service

The fact that AWS and Anthropic themselves released a self-hosted gateway for Claude Code and Claude Desktop confirms the direction: AI tools are no longer managed laptop by laptop, but through a governance layer the organization controls itself. Manthra brings that layer into production and manages it. Manthra also solves the procurement problem: the customer is billed via Cloudar or via AWS Marketplace, with whom a vendor relationship usually already exists, without having to set up its own master agreement with Anthropic or get stuck on practicalities such as paying by credit card.

“AI is maturing. What started as a tool employees tried out on their own is becoming a service the organization relies on, with the same expectations as the cloud: secure, predictable and managed. Yet many companies can no longer see the forest for the trees. There are several ways to acquire Claude, each with different implications for data and billing. Manthra takes over those choices and that management, so IT can focus on what AI delivers,” says Senne Vaeyens, co-founder at Cloudar.

What Manthra delivers

• Web interface: Manthra offers a simple web interface that lets IT and finance manage and track users, limits and usage: add new users, set spending limits, and see at a glance who is using what.
• Compliance: Inference runs within the EU. The customer chooses, per environment, between two retention profiles: Zero Data Retention (no storage of prompts and responses) or a Compliance & Audit profile with encrypted logging to a write-once S3 bucket with its own KMS keys, accessible only to audit teams. For the newest models that fall outside Zero Data Retention, use requires a deliberate opt-in. Amazon Bedrock Guardrails can detect and block personal or sensitive data [to confirm this is live]. Login runs via the existing identity provider (such as Entra ID or Okta), without persistent AWS keys on laptops.
• Cost control: Usage is billed per token at Bedrock rates, with no per-user license. Costs appear on the AWS bill or via Cloudar, whichever the customer prefers. Spending limits per user, group or organization are enforced in real time: once the cap is hit, the gateway blocks further requests until the period resets or an administrator raises the limit. Model access can be managed centrally, with alerts for runaway usage. Routine tasks can be routed to faster, cheaper models, while the heaviest models are reserved for complex work.
• Plug-and-play: The customer doesn’t need to handle complex technical configuration or deployment themselves, unless they want to: Cloudar sets up and manages the environment. Under the hood, the gateway runs as a container in a locked-down AWS VPC, with configuration that IT rolls out to laptops through existing tools (Intune or Jamf), invisible to the customer.
• Management: Cloudar deploys, patches and monitors the environment, makes new Claude models available as soon as they’re released, delivers periodic cost reports, and is the point of contact for incidents.

According to Senne Vaeyens, adoption in regulated organizations comes down to two questions: “Where does our data go, and what will this cost? With Manthra, we can show a CISO step by step where every prompt goes, and give a CFO a per-user cap before a single token is consumed. That’s when AI becomes something you dare to roll out broadly, with confidence.”

Manthra is available in two forms. With fully managed, Cloudar runs a dedicated AWS tenant. With configured on your tenant, Cloudar builds the environment in the customer’s own AWS account and hands it over, with optional support afterwards. Billing can run through Cloudar or through AWS Marketplace. Cloudar starts with a workshop involving business, IT and security, then delivers a plan covering phasing, timing and budget, and moves via a pilot with a handful of early adopters toward broader rollout.

The post Cloudar launches Manthra: Managed Anthropic on AWS appeared first on Cloudar.

And we are particularly proud of what that means locally: Cloudar is the only locally headquartered Belgian AWS Partner authorized to carry the Backed by AWS Support label.

The designation is more than a badge. It means AWS has audited and certified Cloudar to deliver technical support on its behalf. Instead of coordinating between your managed services partner and AWS Support, Cloudar becomes your single point of contact for AWS support.

Our engineers handle first- and second-line support directly. They already know your AWS environment, architecture and workloads. When deeper AWS expertise is required, we can escalate directly to AWS through dedicated escalation paths and work with AWS experts on the issue.

More than an escalation path

Being a Partner-Led Support partner also gives Cloudar capabilities that regular AWS MSPs do not have.

Cloudar engineers have access to additional AWS support and diagnostic tooling, including secure access to a subset of the tools used by AWS Support engineers themselves. This gives us additional service-side visibility when troubleshooting complex AWS issues.

The result is simple: less back-and-forth, faster diagnosis and faster resolution for our customers.

We have also integrated AWS Support directly into our own operations. AWS Support cases are synchronized with our Jira-based service desk through the AWS Support API. When AWS responds, that information flows directly into the same customer ticket our engineers are already working on.

Proactive, not just reactive

Partner-Led Support is not only about fixing problems when something breaks.

Our managed AWS environments are continuously assessed for security, compliance and configuration risks. Findings enter the same operational processes as incidents, allowing our engineers to identify and address potential problems before they become support cases.

For our customers, this means:

• One support channel: Cloudar owns your case from start to finish.
• Engineers who know your environment: no anonymous support queue starting from zero.
• Direct AWS backing: when AWS expertise is needed, we have established escalation paths into AWS Support.
• Exclusive PLS tooling: additional AWS diagnostic capabilities that aren’t available to regular MSPs.
• Faster troubleshooting: better visibility and direct integrations reduce unnecessary back-and-forth.
• Proactive support: we continuously identify risks instead of waiting for incidents.

The Backed by AWS Support label is therefore much more than another AWS badge. It validates the people, processes and technology behind Cloudar’s support organization.

And as the only locally headquartered Belgian AWS Partner carrying the Backed by AWS Support designation, we can combine that direct AWS backing with what has always made Cloudar different: a local team that knows our customers and their AWS environments inside out.

The post Cloudar is now Backed by AWS Support appeared first on Cloudar.

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.