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

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

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

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

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

Lessons from building agents in production

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

1. Use smaller models for simpler tasks

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

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

2. Gatekeep the agent: deterministic first

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

3. Keep prompts compact

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

4. Limit the tools your MCP servers expose

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

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

5. Cap the loop

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

6. Mind your outputs and your history

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

7. Use prompt caching

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

8. Batch what is not urgent

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

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

The practices above, at a glance:

Measure it or it did not happen

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

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

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

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

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

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

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

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

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

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

The bill is coming. Be ready.

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

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

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

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

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

Not deciding is also a decision

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

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

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

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

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

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

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

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

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

Start with insight, then migrate in phases

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

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

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

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

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

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

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

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

Two ways to stop betting the business on one model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pitfall 3: a fallback ladder is also a cost ladder

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

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

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

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

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

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

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

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

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

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

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

What we’d tell our past selves

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

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

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

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

The first one was filed on November 19, 2017. Seven years ago. The ask: let an admin change a customer’s email address in Jira Service Management. Not migrate accounts through a four-step workaround involving Atlassian ID. Just… change an email address. The kind of thing you’d expect a junior developer to ship on a Tuesday afternoon. As of today, it has 779 votes, 447 watchers, and a status of “Future Consideration.” Which, in SaaS-speak, translates roughly to: “we heard you, we filed it, please stop asking.”

The second one landed in January 2019. The request: make Confluence’s alphabetical page sorting persistent, so new pages don’t just pile up at the bottom like uninvited guests. Six years later: 600 votes, 261 watchers, status “Under Consideration.” Progress!

Now, to be fair to Atlassian, they’re not uniquely terrible. Every major SaaS vendor has a graveyard of feature requests exactly like these. Sensible, obvious, clearly wanted by thousands of paying customers. Just… never quite prioritized. Because they have a roadmap. And you’re not on it.

This is the part of the SaaS brochure they don’t show you.

The Pitch vs. The Reality

SaaS vendors are exceptionally good at one thing before you sign: making you feel like you’re about to get exactly what you need. The demos are polished. The slide decks are beautiful. The onboarding is smooth. Eighty percent of your requirements? Covered, on day one.

It’s that remaining twenty percent where things get interesting.

That twenty percent is where your actual workflows live. The edge cases. The things specific to how your organization actually operates. And when you file a support ticket asking about them, you enter a fascinating parallel universe where time moves differently. Features are “on the roadmap.” Updates will come “in a future release.” Your vote has been registered. Thank you for your feedback.

Meanwhile, you’re paying. Every month. For the product as it exists, not as it was promised.

The Numbers Are Telling

The scale of SaaS sprawl is difficult to overstate. According to BetterCloud’s annual State of SaaSOps report, the average number of SaaS applications per company peaked at 130 in 2022 and even after a wave of consolidation, still sits at over 100 today. That’s more than 100 subscriptions to manage, renew, secure, and integrate. For every single organization.

The waste embedded in that sprawl is just as striking. Gartner estimates that approximately 30% of purchased SaaS licenses go unused, what they bluntly call “toxic spend.” BetterCloud puts a price tag on it: companies report wasting an average of more than $135,000 per year on unused software licenses alone. And Gartner projects SaaS spending will continue growing at around 19% annually, reliably outpacing the budgets meant to fund it.

Do the arithmetic on a typical mid-market tool. Fifty users. €50 per user per month. That’s €30,000 per year. Every year. With annual price increases that arrive in your renewal email as a polite fait accompli. After five years, you’ve spent €150,000-plus on software you don’t own, can’t modify, and can’t easily leave and somewhere between a quarter and a third of those licenses have been sitting idle.

Something Changed

Here’s what’s different in 2026: building software got dramatically cheaper and faster. Not incrementally but by an order of magnitude.

Tools like Claude Code and Kiro represent a new category of agentic coding assistants. They don’t just suggest the next line. They can take a requirement, reason through a solution, write the code, test it, catch errors, and iterate, with minimal human supervision. What previously required a team of developers and months of work can now be done by one technically capable person in days.

This isn’t science fiction. It’s happening right now in engineering teams across the world.

And it fundamentally changes the math on one of the oldest questions in IT: should we build or buy?

What You Get When You Build Your Own

When you build a custom application -even a relatively simple internal tool- you build exactly what you need. No more, no less. You control the data model, the workflow, the integrations, and the roadmap. And critically: you decide what gets built next. Not a product manager in Sydney who’s never seen your workflows.

Running on cloud-native infrastructure like AWS means scalability, security, and availability are largely handled by the platform. The operational gap between “something you built” and “something a vendor hosts for you” has narrowed considerably. And the cost gap has flipped.

A custom-built equivalent to that €30,000/year SaaS tool, developed with AI-assisted tooling and running on serverless AWS infrastructure, might cost a fraction of that annually in operational expenses, after a one-time build investment that has also come down dramatically. More importantly: you own the asset. It does exactly what you need. And you’re not waiting seven years for someone to let you update an email address.

A Word of Honesty

Custom software isn’t free of responsibility. Someone has to maintain it, secure it, and evolve it. The SaaS argument, that someone else handles the infrastructure, the uptime and the patches, is not without merit. And for commodity functions like email, video conferencing, or payroll, that argument still wins. These are solved problems. Building your own would be an expensive act of reinvention.

But pairing custom-built applications with managed cloud services gives you the operational coverage of SaaS without the product dependency. You get uptime. You get security. You get to decide what comes next.

So What Should You Actually Do?

Not everything should be custom-built. That would be its own kind of madness.

The question worth asking is simpler: where are your core differentiating workflows? The processes that encode years of operational knowledge. The edge cases that keep showing up in feature request threads, yours and everyone else’s, year after year, status unchanged.

Those are exactly the features that will never quite make it onto a SaaS vendor’s roadmap.

The question is no longer “can we afford to build?” The question, in 2026, is whether you can afford to keep waiting.

JSDCLOUD-5746 would like a word.

The post Dear SaaS Vendor, We’ve Been Waiting Since 2017. appeared first on Cloudar.

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

The Two Paths: Open Standards vs. Proprietary Platforms

The Open Approach: AWS Landing Zone Accelerator (LZA)

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

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

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

The Proprietary Approach: Custom Orchestration Platforms

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

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

Here’s what proprietary platforms typically involve:

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

The Lock-in Mechanisms You Need to Watch For

1. Custom Landing Zones Without Source Code Access

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

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

2. Web-Based Orchestrators That Become Operational Chokepoints

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

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

3. “Simplified” Interfaces That Hide AWS Reality

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

The Real-World Impact of Lock-in

Scenario 1: The Price Increase

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

Scenario 2: The Service Quality Decline

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

Scenario 3: The Strategic Pivot

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

Scenario 4: The Platform Limitation

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

How to Evaluate Your Current or Prospective MSP

Ask these critical questions:

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

The Cloudar Philosophy: Your Cloud, Your Terms

Here’s what that means in practice:

Full LZA Implementation

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

AWS-Native Tooling

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

Comprehensive Documentation

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

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

Open Book Operations

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

Standard AWS Best Practices

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

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

The Economics of Freedom

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

Lower costs come from:

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

Not from locking customers into proprietary platforms.

Better service comes from:

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

Not from proprietary abstraction layers.

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

Making the Right Choice

Before signing with any MSP, ask yourself:

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

Red Flags in MSP Sales Processes

Be wary if you encounter:

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

Conclusion: Freedom as a Feature

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

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

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

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

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

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

Choose freedom.

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

Cloudar Renews AWS MSP Partnership with a Perfect Score!

At Cloudar, we are very proud to announce that we have successfully renewed our AWS Managed Service Provider (MSP) partnership for the second time—and with a perfect score! This achievement further solidifies our position as a leading AWS MSP, ensuring that our clients receive the highest level of cloud expertise and managed services.

A Hard-Earned Accreditation

Achieving the AWS MSP competency is no easy feat. The renewal process involves an extensive and rigorous two-day external audit, where AWS evaluates a company’s capabilities in security, automation, DevOps, customer success and more. This intensive assessment ensures that only the best-in-class providers are recognized, and we are happy to have met and exceeded every requirement.

A Six-Year Legacy of Excellence

Cloudar has been an authorized AWS MSP for six years, continuously demonstrating our ability to deliver exceptional managed services to our clients. This designation reaffirms our deep expertise in AWS technologies, proactive monitoring, and automation, helping businesses optimize their cloud environments while focusing on their core operations.

The Only Belgium-Based AWS MSP

We take great pride in being the only AWS MSP headquartered in Belgium. In a competitive and ever-evolving cloud landscape, this distinction highlights our unwavering commitment to excellence and customer satisfaction. Our local team of AWS-certified experts works tirelessly to provide best-in-class cloud solutions tailored to each client’s needs.

An Exclusive Global Network

The AWS MSP designation is highly exclusive, with only 185 companies worldwide holding this prestigious competency. As part of this elite group, Cloudar continues to set the standard for managed cloud services, ensuring businesses maximize their AWS investments.

Why Work with an AWS MSP?

Partnering with an AWS MSP like Cloudar means businesses can focus on what truly matters: delivering value and innovation. Our expert team handles the complexity of cloud management, security, and optimization, allowing organizations to drive efficiency, reduce costs, and scale with confidence.

We are incredibly proud of this accomplishment and remain dedicated to helping businesses thrive in the cloud. Thank you to our customers, partners, and the entire Cloudar team for making this achievement possible!

Looking for a trusted AWS MSP partner? Get in touch with us today and discover how Cloudar can elevate your cloud journey!

The post Cloudar renews AWS MSP partnership 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.

#1 Hybrid cloud is the new normal

Hybrid cloud approaches take advantage of the scale and security of public clouds while keeping data on-premise or supporting edge computing. In a hybrid cloud, applications run in a combination of different environments. As hybrid becomes a dominant approach, providers will offer more flexible options to fit each customer’s data storage and workload needs. AWS is helping to reinvent the hybrid cloud by extending its infrastructure and services to customers wherever they need it.

Rather than offering a clunky mish-mash of tools and environments, AWS extends the cloud to where customers’ on-premises applications reside. Cloud infrastructure and services are deployed wherever they are needed for a consistent cloud experience. To stay competitive, platforms like AWS are focusing on industry-specific cloud products offering features and functions focused on sectors like finance, healthcare and telecom. AWS Outposts is a set of fully managed solutions delivering AWS infrastructure and services to virtually any on-premises or edge location for a truly consistent hybrid experience!

#2 Security is more essential than ever

The cloud opens up tremendous possibilities to boost efficiency and convenience. It also exposes companies to new cybersecurity threats. Compliance is also an issue, as there is more and more legislative restriction around how companies store and use personal data. Trust is everything, and keeping customer data safe is essential to stay in business.

All this contributes to cybersecurity being a higher priority than ever for global business. For companies balancing security with rising costs, it is essential to find innovative ways to save costs while optimizing security. A prime moment for AI and predictive technology to step in and help identify potential threats. There’s no question that investing in security pays off, so expect cloud security to be a huge growth segment.

#3 The cloud drives sustainability

Companies are relying on the cloud to help meet their sustainability goals by boosting efficiency while minimizing their environmental footprint. AWS designs sustainable and low-cost workloads that help brands reduce carbon emissions, energy consumption and waste. The impact is real, with AWS working to help Amazon achieve their goal of switching to 100% renewable energy.

Public cloud servers are much more efficient than traditional data centers due to highly utilized infrastructure. Moving software from hardware systems to the cloud also makes a major dent in energy consumption.  AWS can help customers lower their IT carbon footprint by a huge percentage, reducing emissions from consumed energy purchases. AWS is also pioneering water stewardship initiatives for a more efficient use of water resources. In times defined by accelerating climate change, there is no doubt that the environmental case for moving to the cloud is strong.

#4 The low- and no- code revolution

Low-code and no-code solutions are poised to make a major impact on the tech landscape. These tools and platforms allow anybody to build websites, applications and a wide range of digital solutions with little to no coding skills. They are even becoming available to create AI-powered applications. The timing couldn’t be better as it helps to compensate for the talent shortage of a booming IT sector and help accelerate digital transformation. Benefits include increased automation capabilities, faster turnaround, reduced error and greater accessibility. It’s safe to say that low- and no-code are going to be used for a majority of development in the near future.

The key is of course, the cloud, where users access these solutions as a service instead of having to own the computing infrastructure needed to run them. This is yet another area where the cloud is a major driver of innovation. AWS has been at the forefront of the low- and no-code revolution with Amazon Honeycode for building apps, AWS Amplify Studio for web-app development and no-code platform SageMaker Canvas for machine learning (ML). We’ll provide more details about the latest AWS announcements and innovations in low- and no-code in an upcoming blog!

#5 AWS solutions to keep your eye on

There were lots of other exciting developments announced at the end of 2022 at AWS re:Invent, giving us lots to look forward to in 2023. Here are just a few of them:

• SimSpace Weaver: this new managed compute service simplifies the creation of huge spatial simulations with multiple data points without hardware restrictions.
• Application Composer: this tool is set to speed up the development process of serverless applications. It maintains deployment-ready infrastructure as code definitions and offers a browser-based visual canvas.
• Amazon Security Lake: this service automatically centralizes security data from all on-premises and cloud sources so analysts can aggregate, manage, and optimize huge volumes of data to respond to security threats.

There’s lots more in store: keep an eye on our blog for more juicy AWS developments!

AWS Managed Services Providers (MSPs) like Cloudar help you tap into the opportunities of AWS more efficiently and securely. Want to know how we can help you accelerate innovation? Get in touch!

The post 2023 in the AWS cloud: 5 trends to look out for appeared first on Cloudar.

#1 Downtime don’ts

AWS is very secure, but network issues at data centers do happen. Luckily there are AWS Availability Zones to route workload across several data centers within an AWS region to reduce the risk of downtime. Distributing workloads across multiple servers can also balance workloads. Horizontal partitioning provides extra redundancy to each app stage. Redundant instances should be located in various availability zones to reduce inevitable downtime.

#2 Access uh-ohs

If we don’t restrict administrator access, we can end up giving data access to unintended parties. This is a prime opportunity for hackers to exploit valuable data and customer information. It’s important to take the right precautions before switching over to AWS. This includes verifying cloud management and security systems before transferring information. In addition to rigorously restricting physical access, securing passwords and access keys according to AWS best practices is crucial. AWS procedures regarding compromised data should be followed in the case of a breach.

#3 Certificate concerns

This big blunder is often overlooked. Certificates that expire without notice can cause major mayhem. To avoid inconvenient outages and other chaos, apply AWS Config monitoring to all AWS ACM-based certificates to alert people to expiring certificates in advance. Also enable automatic renewals for internal certificates. Limit the use of single certificates to decrease the impact of any outages. It’s all part of prioritizing certificate management before migrating to AWS, looking at how certificate will be tracked and renewed and who will issue them.

#4 Configuration chaos    

Misconfigurations are a major source of attacks. Data can end up being exposed if there isn’t enough authentication needed. Misconfiguring network functionality or providing system users with too much access can also be a vulnerability, as are exposed passwords and keys. Misconfigured APIs are also at the root of many breaches. This is where change management practices come in. It’s essential that this receives due attention, and that multiple people are charged with looking at what is configured and how to manage risk.

#5 High priced hiccups

While AWS delivers cost-effective infrastructure and services, it’s common for organizations to underestimate costs while evaluating services. AWS users don’t always keep track of their capacity utilization, which impacts the cost. They wind up underutilizing AWS services which they are billed for. Using AWS EC2 reserved instances reduces application computation expenses. Careful tracking of what resources are used avoids unnecessary costs. AWS Trusted Advisor can be used to keep track of AWS charges.

AWS partners like Cloudar are there to help you leverage the power of the Cloud in the safest and most cost-effective way. Reach out to us to talk about how we can work together!

The post Bumps in the road: 5 AWS cloud adoption pitfalls to watch out for appeared first on Cloudar.

Shared responsibility model 

Security and Compliance falls under the shared responsibility model between AWS and the customer. Under this model, AWS takes on some of the customer’s operational burden by operating, managing and controlling certain system components as well as the physical security of the facilities in which the service operates. Meanwhile the customer is responsible for the guest operating system, other associated application software as well as the configuration of the AWS provided security group firewall. This model helps share the load while providing flexibility and customer control. 

Under the shared responsibility model, AWS is responsible for the security “of the cloud”, protecting the infrastructure including the hardware, software, databases, networking, and facilities that run AWS Cloud services. The customer is charged with security “in the cloud”, and their responsibility will be determined by the AWS Cloud services they select, which impacts the amount of configuration work they must perform. Their remit includes data protection, identity and access management (IAM), OS configuration, network security and encryption.

Top security considerations 

Here are some of the top security challenges to keep in mind when migrating to the cloud:

• Regulatory and compliance requirements: The cloud environment must meet regulatory requirements and compliance requirements. AWS will have their regulatory requirements covered, but under the shared responsibility model the customer must ensure that they meet privacy requirements on their end, especially concerning sensitive information and access. They may also need specialized controls to meet certain industry requirements.
• Visibility and monitoring: Cloud environments like AWS are large and complex, and contain a wide array of settings to monitor. Security teams may struggle to understand what is going on in cloud environments, especially because cloud migrations imply dynamic change. Provisioning and decommissioning cloud assets rapidly and technical complexities can make security difficult to manage. Gaining visibility is key to identifying dark data and handling data privacy. It’s important to employ industry best practices for initial risk assessment, configuration and security, followed by careful monitoring.
• Managing DevOps: The DevOps team includes developers and infrastructure specialists who manage the DevOps pipeline: coding, building, validation and deployment. When migrating to the cloud, they are responsible for integrating security tools and addressing security issues. They also have to protect against threats when workloads and applications go live.
• Governance standards: Governance workflows and alignments need to become more agile in the Cloud, involving a wider variety of stakeholders. Establishing a set of security standards and baselines in collaboration with the governance team is key. A cloud governance committee can ensure cohesion across teams.
• Protecting network traffic: Just like traditional environments, cloud-based environments can be targets for malware, bots and data breaches. It is essential to control data privacy and protect against cyber threats while securely connecting the cloud to on-premises networks. Information security should be employed to maintain network security parameters.

The way forward 

While it’s important to always carefully account for security considerations, it should still be a no-brainer to go ahead and migrate to the cloud. After all, it’s the new normal for enterprise IT operations. Working with a consulting partner like Cloudar, companies can create a migration roadmap suited to their specific organization. This of course includes all the particulars of their industry and configuration needs. Not only will this make cloud migration more efficient and advantageous, it allows companies to benefit from Cloud Best Practices including security. 

As a Premier Consulting partner, Cloudar has a proven track record of migrating applications and infrastructure to the Cloud. Want to know more about how we execute secure migrations from start to finish? Reach out to us today. 

The post Seamless & secure cloud migration: top things to consider appeared first on Cloudar.