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

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

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

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

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

Lessons from building agents in production

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

1. Use smaller models for simpler tasks

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

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

2. Gatekeep the agent: deterministic first

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

3. Keep prompts compact

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

4. Limit the tools your MCP servers expose

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

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

5. Cap the loop

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

6. Mind your outputs and your history

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

7. Use prompt caching

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

8. Batch what is not urgent

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

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

The practices above, at a glance:

Measure it or it did not happen

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

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

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

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

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

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

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

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

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

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

The bill is coming. Be ready.

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

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

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

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

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

Not deciding is also a decision

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

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

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

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

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

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

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

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

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

Start with insight, then migrate in phases

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

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

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

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

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

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

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

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

Two ways to stop betting the business on one model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pitfall 3: a fallback ladder is also a cost ladder

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

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

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

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

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

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

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

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

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

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

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

What we’d tell our past selves

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

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

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

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

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

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

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

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

Cost vs ROI

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

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

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

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

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

Public trust as a strategic objective

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

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

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

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

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

Cloudar has achieved the AWS Global Security & Compliance Acceleration (GSCA) certification, underscoring our commitment to providing secure, compliant cloud solutions. For AWS users, this milestone brings several benefits, helping them streamline operations, meet compliance requirements, and ensure the highest levels of security.

About the AWS Global Security & Compliance Acceleration Program

AWS designed the GSCA program to support partners in strengthening the security and compliance of cloud environments. Through the GSCA program, we have gained access to advanced training, resources, and AWS experts, enabling us to fine-tune our security capabilities and stay ahead of ever-evolving threats.

This program emphasizes automation, governance, and continuous monitoring, empowering us to proactively address security challenges and scale securely in the cloud.

Enhanced security posture

With this certification, Cloudar can provide customers with ready-to-go security solutions, customized to fit their unique requirements. From secure infrastructure setup to automated incident response, we can ensure your workloads are protected from day one.

By adhering to AWS’s best practices, we can ensure that your infrastructure is secure by design. We leverage tools like AWS Security Hub, Amazon GuardDuty and AWS Config to provide customers with continuous threat detection, rapid incident response, and real-time insights into security events. This means your business can identify and mitigate risks before they escalate.

Regulatory compliance

Compliance is no longer an afterthought. Cloudar uses AWS-native tools to continuously monitor for regulatory compliance and offers pre-built templates to help meet industry standards, reducing the time and effort required to maintain compliance.

Whether your business operates in a heavily regulated industry like healthcare, finance, or government, the GSCA certification ensures that we can help you meet key regulatory requirements such as GDPR, HIPAA, SOC 2, and more.

Faster time-to-market:

By automating security and compliance processes such as patch management, configuration drift detection, and log monitoring, we can significantly reduce the time it takes to implement secure, compliant workloads on AWS.

Cloudar ensures that our customers can maintain a high security posture without the overhead of manual intervention. This leads to lower operational costs and more efficient resource allocation, so you can focus on innovation and growth, while we handle the complexities of cloud security.

Cloudar helps you leverage the power of AWS Security

Cloudar’s approach goes beyond simply implementing AWS’s built-in tools. We work closely with your teams to tailor solutions that fit your specific business needs, ensuring that you get the most out of the AWS cloud while keeping your data secure and compliant.

We design cloud architectures that follow AWS’s security best practices, but are customized to fit the scale, complexity, and compliance needs of your business.

Whether you’re migrating to the cloud or optimizing existing workloads, Cloudar ensures a smooth integration of AWS security services with your current operations.

But our support doesn’t stop after deployment: Cloudar continuously monitors your cloud environment, ensuring you stay compliant and secure as your business grows.

The Cloudar Difference

At Cloudar, we understand that security and compliance aren’t just checkboxes – they’re critical to building trust with your customers and staying ahead in a competitive market.

By achieving the Global Security & Compliance Acceleration on AWS, Cloudar once again proves that we are not just a partner, but a trusted ally in your cloud journey.

We provide peace of mind that your AWS workloads are not only running efficiently but are also secured against threats and aligned with the latest regulatory standards.

If you’d like to learn more about how Cloudar can enhance your cloud security and compliance, or if you’re ready to take your AWS workloads to the next level, don’t hesitate to get in touch with our team today!

The post Achievement Unlocked: Global Security & Compliance Acceleration on AWS appeared first on Cloudar.

We’re thrilled to announce that Cloudar will be attending AWS re:Invent 2024 in Las Vegas! As the biggest annual gathering for cloud enthusiasts, experts, and innovators, AWS re:Invent offers countless opportunities to learn, connect, and discover what’s new in the world of cloud technology. But with so much happening—from keynotes to hands-on labs, networking sessions to deep-dive discussions—it can sometimes feel overwhelming to navigate everything this event has to offer.

That’s why we initially developed our re:Invent Chatbot, a friendly assistant designed to make your re:Invent experience smoother and more enjoyable! While we’re excited to share the concept, due to AWS guidelines, the chatbot will not be available for use at this year’s event. However, the development of this tool still serves as a great example of how cloud-driven AI can transform the event experience.

Meet the re:Invent Chatbot – A Vision for Personalized Event Assistance

Even though the chatbot is offline for now, it’s an exciting demonstration of how technology can make large-scale events like AWS re:Invent easier to navigate. Whether you’re searching for the perfect session, need quick answers to FAQs, or just want help organizing your schedule, the chatbot was designed with the user in mind.

Here’s what the re:Invent Chatbot would have been able to do:

• Session Navigation: With hundreds of sessions happening at once, it’s easy to lose track. Our chatbot could help you quickly find sessions that match your interests or needs—just ask for recommendations, and you’d be pointed in the right direction.
• Answer FAQs: From event logistics to session details, the chatbot was equipped with a wealth of knowledge to answer questions on the fly.

Taking it Further: Imagine a Chatbot for Music Festivals

Let’s take the concept one step further. Imagine attending a large music festival with dozens of stages and hundreds of performers over a few days. It can be daunting to decide who to see and when. That’s where a Music Festival Chatbot could come in handy.

For example, you could tell the chatbot your favorite genres—let’s say you’re into electronic music, indie rock, and a bit of jazz on the side. The chatbot could take that input and instantly suggest a personalized lineup for you, complete with the times and locations of each performance. It could also help you with last-minute schedule changes or even recommend food trucks or merch stands nearby during set breaks.

Here’s what this Music Festival Chatbot could do:

• Personalized Lineup Recommendations: Based on your music preferences, the chatbot could suggest artists, DJs, or bands you might enjoy, even introducing you to new acts within your favorite genres.
• Time Schedule: Once your lineup is set, the chatbot could create a custom schedule for you which you could use throughout the event.

Just like our re:Invent Chatbot concept, this Music Festival Chatbot shows the potential of AI to personalize experiences, turning chaotic, multi-day events into seamless, curated adventures.

Why Build a Chatbot?

At Cloudar, we believe that technology should make life simpler, not more complicated. The re:Invent Chatbot embodies that philosophy. By leveraging cloud-based AI, we aimed to enhance attendees’ experiences, reducing the stress of juggling schedules or missing key moments.

Though the tool won’t be live this year, we hope it sparks inspiration for the many possibilities that cloud technologies can offer in the future. And, of course, we’ll be keeping this idea in our toolkit for future events.

Let’s Connect in Las Vegas!

We can’t wait to see you at AWS re:Invent 2024! If you’re attending, don’t hesitate to reach out—we’d love to grab a cold beer together and chat about all things cloud. Whether you want to talk about AWS, share your re:Invent experience, or discuss how tools like the re:Invent Chatbot could evolve, we’re always eager to connect.

The post Cloudar at AWS re:Invent 2024 – Your Guide to an Unforgettable Experience appeared first on Cloudar.

1 day published by ENTSOE

12 days predicted by EPPM

The Need for Advanced Forecasting

In our era of energy efficiency and cost management, accurate electricity price predictions are a game-changer. For businesses, this means optimizing operations and reducing costs. For consumers, it translates to better planning and substantial savings. EPPM employs state-of-the-art machine learning algorithms and AWS services to deliver highly accurate electricity price predictions.

How EPPM Works

EPPM utilizes a comprehensive approach, integrating various data sources and sophisticated analytical techniques to generate precise forecasts. Here’s a step-by-step breakdown of the process:

• Data Collection: Every day at 3 a.m., our system kicks off data collection using AWS Step Functions. We gather information from multiple sources, including weather data, historical energy prices, and other relevant factors, all stored in Amazon S3.

• Data Preprocessing: The raw data undergoes meticulous cleaning and processing using AWS Step Functions and AWS Lambda, ensuring consistency and reliability—the foundation for accurate predictions.

• Model Training: Every Monday, new models are trained using Amazon SageMaker with the latest datasets. Hyperparameters are optimized, and the most effective model is saved in Amazon S3 for future predictions.

• Prediction Generation: Leveraging the best-performing model, predictions are generated daily using Amazon ECS at 11 a.m. These forecasts offer a detailed view of hourly electricity prices for the upcoming weeks, saved into another S3 bucket.

• Data Delivery: The predicted data is delivered via a REST API running inside AWS ECS on a Fargate container. This API is consumed by a frontend application, also running as a Fargate container, ensuring scalability, reliability, and seamless integration. Users can select date ranges and view comprehensive graphs comparing predicted and actual prices through an intuitive interface.

Real-World Applications

The applications of EPPM are extensive. Businesses can optimize their energy consumption by scheduling energy-intensive operations during low-cost periods. Utility companies can better balance supply and demand, reducing the risk of outages. Regulatory bodies can use these insights to develop policies that promote sustainable energy practices.

Conclusion

Predicting electricity prices weeks in advance is set to revolutionize energy management. EPPM not only provides this capability but does so with exceptional precision and dependability, thanks to AWS native services. As EPPM evolves, it promises to make a significant impact on the energy sector, driving efficiency and sustainability.

Imagine a future where energy usage is perfectly optimized, leading to substantial savings and a greener planet. With EPPM, that future is within reach.

The post EPPM: Forecasting Energy Prices with Precision appeared first on Cloudar.

At Cloudar, our break room isn’t just for coffee breaks – it’s the battleground for the legendary ‘Pinball Grand Champion Cup.’  – a prestigious, though temporary, ownership. Every few months, we swap out the pinball machine, igniting a fresh round of competition. This means that every three to six months, we must ‘relearn’ a new game, which, while fun, can be a distraction from our actual (#AWSome) work. Some of us embrace the challenge as a delightful learning experience, while others simply want to know how to do multi-balls & gain extra bonusses.

Enter Claude Chatbot (aka Pinbot)

But, learning each new game can be a bit of a time sink, right? That’s where our latest creation, the Claude Chatbot on AWS, comes into play. It is a chatbot with RAG (Retrieval-Augmented Generation) capabilities. This means Claude can be loaded up with a wealth of knowledge from various sources like PDFs, YouTube videos, spreadsheets, even webpages.

Instead of loading Claude with legal texts or company manuals, I thought, “Why not make him a pinball wizard?” So, I programmed Claude to become the ultimate guide for our Teenage Mutant Ninja Turtle pinball machine. I fed it YouTube videos of expert players, detailed rule sheets, and tips on mastering the game. In just a few minutes, TMNT Pinbot was ready to roll.

Playing Like a Pro

Imagine standing in front of the pinball machine, unsure of your next move. You simply ask TMNT Pinbot, “How do I play as Michelangelo?” and within seconds, it gives you the exact shots you need to make. No more endless YouTube searches – instant answers and higher scores. This saves time, and increases revenue (or in this case; your score on a pinball game). Plus, the Pinbot can reference its sources, so you can see exactly where the tips are coming from.

Beyond Pinball: Claude’s Endless Possibilities

Sure, the Pinbot is a fun & quick gimmick, but Claude Chatbot’s potential goes far beyond gaming. Picture a world where your company’s entire knowledge base is just a question away. Need to check a guideline? Ask Claude. Trying to find a procedure buried in a mountain of documents? Claude’s got it. This isn’t just about saving time – it’s about enhancing productivity and ensuring consistency across the board; no more risky “creative” interpretations of your procedures/documentation.

Real-World Applications

Imagine a repair bot for mechanics. Instead of combing through bulletins for error code 678, a mechanic could just ask the bot and get immediate, accurate suggestions. Or think about a compliance bot that ensures all your creative marketing ideas meet company policies. No more guessing if your booth design follows the AWS logo rules – just ask the bot, and it’ll tell you.

The Future is Conversational

The Pinbot is just a fun demo, but it shows how powerful conversational interfaces can be. As we continue to refine our Claude Chatbot’s capabilities, we’re excited to see how this technology will revolutionize workplaces; From saving time to ensuring compliance. The future of work is conversational, and Cloudar is leading the charge.

Stay tuned for more use cases!

The post Meet our Pinbot Powered by Claude appeared first on Cloudar.

At Cloudar, we are always on the lookout for innovative ways to enhance our operations and provide top-notch services to our clients.

That’s why we’re excited to introduce our Claude Chatbot, an AI-powered chatbot running entirely on AWS infrastructure.

This powerful tool utilizes Aurora VectorDB, AWS Bedrock, and Claude Opus/Sonnet/Haiku to offer a customizable, efficient, and secure solution for all your chatbot needs.

Customizing Your Chatbot

One of the standout features of Claude Chatbot is its customizability. You can tailor the chatbot to meet your specific needs by uploading your own knowledge base. This makes the chatbot not only a general assistant but also an expert in your chosen domain.

• Upload Documentation: Prepare the documentation or information you want the chatbot to know. This could be anything from company policies to technical manuals.
• Train the Chatbot: Upload this documentation to the chatbot. The AI will process this information and integrate it into its knowledge base, making it a permanent part of its understanding.
• Create Custom Bots: You can create multiple bots for different purposes. For instance, at Cloudar, we have a bot specifically for internal use that contains detailed information about our company.
• Expose as API: Any custom chatbot with custom knowledge can be exposed as an API, allowing other applications to interact with it seamlessly.

Claude can support a wide range of knowledge sources, including but not limited to URLs, PDFs, Office files, text files, and even YouTube videos (links)!

Generative AI: The Core of Claude Chatbot

Claude Chatbot leverages the power of Generative AI to provide advanced capabilities that go beyond simple query responses. By using generative models, Claude can:

• Generate Detailed Responses: Craft detailed, contextually relevant responses based on the input it receives.
• Understand Nuanced Queries: Handle complex and nuanced questions with ease, providing accurate and helpful answers.
• Adapt and Learn: Continuously improve its performance based on interactions and newly uploaded knowledge.

Benefits of Using Claude Chatbot

By leveraging Claude Chatbot, you gain several advantages:

• Enhanced AI Capabilities: The Claude models (Opus, Sonnet, and Haiku) provide state-of-the-art natural language understanding and generation.
• Generative AI Power: With Generative AI at its core, Claude Chatbot can create meaningful and contextually appropriate responses, enhancing user experience.
• Data Ownership: All your data is stored within your AWS account, ensuring you retain complete control over your information.
• Easy Customization: Tailor the chatbot to your needs by uploading specific documentation, making it a valuable tool for both internal and external use.
• API Integration: Expose your custom chatbot as an API, enabling seamless interaction with other applications.
• Scalability: Running on AWS infrastructure means the chatbot can scale effortlessly with your needs, whether you’re a small startup or a large enterprise.
• Seamless Billing: All usage and charges are billed through your AWS bill. No new contracts required.

Setting Up Claude Chatbot

Deploying the Claude Chatbot is a breeze, thanks to its seamless integration with AWS. Here’s how we do it:

1. Provisioning Your AWS Account: We take care of setting up your AWS account, ensuring all necessary services are ready to go.
2. One-Click Deployment: With just one click, we deploy the full infrastructure to your AWS account, thanks to the AWS Cloud Development Kit (CDK). This includes, but is not limited to:

• Aurora VectorDB for optimized data handling
• AWS Bedrock to support AI applications
• API Gateway (APIGW) for managing API requests
• Lambda Functions for serverless compute
• S3 Buckets for scalable storage
• DynamoDB for fast and flexible NoSQL database services
• And more necessary AWS services to ensure a robust and scalable deployment

3. Aftercare and Support: Our commitment doesn’t end at deployment. We provide comprehensive aftercare and support to ensure your Claude Chatbot runs smoothly and efficiently.

Case Study: Cloudar’s Custom Chatbot

At Cloudar, we have multiple custom bots at our disposal:

• Internal Knowledge Bot: This bot is equipped with detailed information about Cloudar, assisting us in everything related to our company.
• AWS Services Bot: This bot contains comprehensive knowledge about some of the major AWS services, helping our team stay informed and up-to-date.

These custom bots have significantly improved our efficiency and reduced the time spent searching for information.

Conclusion

Claude Chatbot represents a significant step forward in AI-driven customer service and internal assistance. Its integration with AWS infrastructure makes it a robust, scalable, and secure solution. By leveraging Claude’s Generative AI capabilities and customizing the chatbot with your own knowledge base, you can transform the way you interact with your clients and team members.

Ready to get started? Let us handle the setup and deployment, and experience the future of AI-powered assistance with Claude Chatbot on your AWS account today.

The post Start Leveraging the Power of Generative AI with Our Claude Chatbot on AWS appeared first on Cloudar.

At Cloudar, we pride ourselves on being the only local Premier AWS partner in Belgium. While global system integrators (GSIs) offer their services on a massive scale, we believe that being a smaller, local player comes with unique advantages. In this post, we’ll explore the benefits of partnering with a local AWS expert like us compared to working with a large GSI.

1. Personalized Attention and Customized Solutions

Unlike larger firms where clients might feel like just another number, we provide personalized attention to each of our clients. Our team takes the time to understand your specific needs, crafting customized AWS solutions that align perfectly with your business objectives. This tailored approach ensures that your company receives the exact support it needs to thrive.

2. Agility and Flexibility

In today’s fast-paced business world, agility is key. Our smaller size allows us to make quick decisions and adapt to your needs rapidly. This flexibility extends to our service offerings, ensuring scalability that supports your business’s growth every step of the way.

3. Local Market Understanding

Our in-depth knowledge of the Belgian market sets us apart. We’re not just AWS experts; we’re experts in how AWS services can best be utilized in Belgium, considering local regulations and market trends. This local insight is invaluable for ensuring compliance and tailoring solutions that work best in our specific market environment.

4. Direct Communication and Stronger Relationships

Working with us means you’ll have direct access to our team of experts. At Cloudar we don’t work with offshoring or nearshoring. This ease of communication fosters stronger, more meaningful relationships. We’re not just a service provider; we’re a partner invested in understanding and contributing to the long-term success of your business.

5. Competitive Pricing and Cost-Effectiveness

We offer competitive pricing that challenges larger GSIs, ensuring that you receive top-notch AWS services without an exorbitant price tag. This cost-effectiveness is part of our commitment to providing value, ensuring that your investment in AWS services yields the maximum return.

6. Community Engagement and Support

As a local business, we’re deeply involved in the Belgian community. We believe in supporting local initiatives and contributing to the local economy. By choosing us, you’re not just getting an AWS partner; you’re contributing to the broader community and fostering local business ecosystem growth.

Choosing a local AWS partner like Cloudar offers a range of benefits that large global system integrators can’t match. From personalized service to local market expertise, our team is dedicated to providing the best possible AWS solutions tailored to your specific needs. If you’re looking for an AWS partner that values your business and is committed to your success, look no further. Contact us today to discuss how we can help your business thrive with AWS.

The post Shop Local appeared first on Cloudar.