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

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

The sigh is a signal

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

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

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

The post The sigh surcharge appeared first on Cloudar.

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.

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

The invoice as a symptom

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

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

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

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

KarmAI

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

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

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

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

On-prem is capitulation

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

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

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

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

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

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.

Getting people to include Cloud financial management and FinOps principles in their daily operation of the cloud is what FinOps professionals like me have been striving for. With FinOps principles integrated more and more into standard cloud practice, an interesting question arises: should the FinOps engineer and the cloud engineer be two separate roles?

If we take DevOps as a precedent, we could argue that there is no way to do cloud engineering without being knowledgeable about DevOps principles and practices. The same could be said of FinOps: It is impossible to do quality cloud engineering without being aware of FinOps principles and best practices.

But wait, isn’t there a shared responsibility model for FinOps too? If we take that shared responsibility model, we can add the “cost efficiency in the cloud” to the responsibilities of the cloud engineers. That leaves us with the “cost efficiency of the cloud”, which surely means FinOps is here to stay? Yes and no. While the knowledge to properly ensure cost efficiency of the cloud is highly specific, the role filling up this layer of the FinOps shared responsibility model is akin to that of a program manager. Say hello to the FinOps Program Manager!

As FinOps becomes more of a tool in the toolbox of Cloud engineers rather than a separate practice (as should be the case), we need Program Managers to maintain and manage FinOps as a program within organizations. FinOps Program Managers are responsible for distributing knowledge, enabling managers and engineers in their access to the right information and making sure the organization has a clear way forward in developing FinOps.

In essence, FinOps becomes a knowledge space or practice utilized by cloud engineers and the program to ensure the cloud is adopted properly within the organization’s tech landscape. A dedicated FinOps profile is responsible for gathering and maintaining that knowledge. In practice, we often see this person and the FinOps Program Manager being one and the same. They are the driving force in gathering and maintaining cloud billing and cost optimization knowledge and supporting FinOps program management efforts within the organization. Based on their efforts, managers and cloud engineers can make informed decisions and have productive conversations on how to improve their cost efficiency in the cloud.

The bottom line: For FinOps to succeed in an organization, there is a strong need for a FinOps Program Manager who can lead up and down the chain of command and steer the course to keeping the shared responsibility model for FinOps in place.

Want some support to help your company get the most out of the cloud? Reach out to us!

The post Cloud cost optimization? Say hello to the FinOps Program Manager appeared first on Cloudar.

FinOps: Consolidated tooling space

While there were no straightforward announcements done by AWS on the FinOps front, a lot of things were said and shown during the sessions. While we can’t make all of it publicly known yet, it is clear that AWS is consolidating their tooling space, which consists of three parts: Billing, Analysis and Visualization.

• Billing: AWS is strengthening the Billing Conductor they released earlier this year and releasing some features that were previously only available to customers through third-party tooling. The fact that they can push CURs for specific billing groups natively (though the cost remains steep), is interesting because it feeds nicely into their visualization tooling.
• Analysis: Cost Explorer had received a visual update just before re:Invent, but other than that no real announcements were made. We talked to some people about the checkboxes, and the general sense is that grouping by multiple layers will come out soon, making Cost Explorer even stronger in comparison to the current version.
• Visualization: the CUDOS or Cloud Intelligence Dashboards were omnipresent at re:Invent, and AWS is really investing in the tool. The fact that customers can use the separate CUR files of the AWS Billing Conductor to create different dashboards for different subsets of accounts is powerful. If this were to become a service or something that you don’t have to build and maintain yourself, it could really rival some of the existing tooling out there.

Right now these three parts are developed by three teams and not really coupled together. They function differently, are priced and billed differently and require quite a lot of custom development to get to a level where third party tools are out of the box. The fact that you can’t carry over billing groups into a restrictive view in Cost Explorer or automate reporting from a Cost Explorer report (the sending of the report that is), are some basic functions that we still miss. Still, AWS is investing in the native tools and investing properly, with attention to feedback from the user community. This is great to see!

GreenOps: Still a long road ahead

On the sustainability front, it was nice to hear AWS pledge on water positivity by 2030. But there is still much work to be done to make the cloud greener. The current reporting on carbon emissions is not up to standard yet, and it does not integrate with for example a QuickSight dashboard or other dashboarding tools. A discussion on what information is really relevant concerning sustainable resource efficiency is also necessary. Why don’t we start looking at the energy consumption of AWS resources? If AWS data centers are truly carbon neutral by 2025, is this not something we should start incorporating in our logged metrics?

While re:Invent gave us a great feeling in terms of FinOps and AWS’s awareness of cost analysis and cost optimization tools, GreenOps seems like it has yet to earn a serious seat at the table aside from having a reporting tool available and some key pledges to improve their ecological footprint.

What did you take away from re:Invent, or what changes in the world of cloud computing would you like to see? Together we can build a sustainable future!

The post re:Invent 2022: General takeaways on FinOps & GreenOps appeared first on Cloudar.

Taking control of the balance between your cloud cost and the business value achieved is challenging. Cloud Financial Management is a detailed, complex discipline that requires people to collaborate with stakeholders across their organization. Most of reviews on the market today offer to assess how well you implement their flavor of FinOps and their framework. We on the other hand, want to assess how and where you can improve your own concrete FinOps practice. Our tool is based on nearly a decade of AWS experience, numerous green-field set-ups, migrations, optimizations, custom development tracks and more.

The Cloudar FinOps Review incorporates our own lessons learned and experience, ensuring that our questions and criteria are paired with no-nonsense, actionable measures that let you start optimizing directly. Even better, Cloudar can give you a hand: we have the knowledge and resources to back up your implementation and optimization track. With over 100+ AWS certifications, we deliver quality work and always strive for excellence.

The post Releasing the Cloudar FinOps Review: everything you should know! appeared first on Cloudar.

#1 Business value 

This principle demands that decision-making is driven by the business value of the cloud. The team that manages your cloud setup should always keep in mind how they can optimize the business value when building, designing and finetuning your cloud infrastructure. With the help of FinOps, you can evaluate your results by comparing them with your industry peers. Learn from best practices and let team benchmarking drive you to improve and excel.

#2 Centralization 

FinOps needs a centralized and committed team to run smoothly and efficiently. Financial data should be collected and analyzed in one place. This ensures general oversight into cloud costs and spending. The need to up- or downscale and any opportunity to optimize the budget becomes visible a lot faster. Any additional purchases or negotiations can be combined to receive the best possible pricing.

#3 Collaboration 

For FinOps to work, all the teams involved need to collaborate consistently. This thorough way of collaborating will allow for your teams to learn from each other. They will be able to build on that new knowledge and constantly review their way of working, which will level up their workflow and processes. Collaboration encourages teams to take a fresh look at their tasks from the point of view of their collaborators. It will encourage them to try new things and take into account how their actions might affect their fellow collaborators. This ultimately results in enhanced creativity, innovation and efficiency.

#4 Opportunity

Working in the cloud comes with a whole new range of opportunities. Organizations are able to design their cloud infrastructure to perfectly fit their needs. This is not a static situation: it can be scaled up and down as needed. This customizability also means that you only pay for what you actually use. Make sure you make the best use of the variable cost model the cloud has to offer to get the most out of your budget.

#5 Ownership

FinOps can only work if all involved cloud users take ownership of how they use the cloud environment. Each team needs to feel empowered enough to take responsibility for their own cloud budget and usage. A very useful tool to use is to set team-level targets. Every cloud collaborator will feel accountable and eager to achieve their targets, and every team member will feel involved and carry their own weight.

#6 Transparency

The only way FinOps can generate trustworthy results is by making sure the data is collected and analyzed correctly and consistently. This data can then be translated into reports for further follow-up. It’s very important that these reports are generated on a regular basis. They should be made accessible to all the teams involved. Fast feedback gives you the chance to react and adjust when necessary.

Cloudar is an active member of the FinOps Alliance. Do you need guidance on implementing the principles of FinOps? Do you want to optimize your cloud spendure without losing oversight? Contact us and let’s find out how we can help make these principles a part of your organization’s culture!

The post Your guiding lights: The 6 principles of FinOps appeared first on Cloudar.

Ease of mind

With FinOps Shared Responsibility Model organizations can rest assured that cost optimization doesn’t just rest on their shoulders. Together with a FinOps expert the customer can share the responsibility of cost efficient working in the cloud on all levels of the operation. The FinOps expert will lay out guidelines and install the necessary guard rails. They will take on cost monitoring and rate optimization. The company’s engineers on the other hand are responsible for the cost efficiency of their solutions and architecture.

Putting it into practice

If you want to make shared responsibility work and engage all stakeholders in doing their part, clear communication and reliable data monitoring are key. Consistent monitoring and reporting are essential if you strive to produce trustworthy data. Which you definitely want if you are looking to optimize your operational costs. They allow companies to evaluate where you need to invest more or maybe less. With correct data, honest communication and critical analysis, an organization can quickly determine where they can innovate and finetune their processes. And more so: how they can do this within their budget and at minimal cost. Maybe even freeing up resources for taking their operations to the next level.

Want to know more about FinOps Shared Responsibility Model? Read all about it in this article by the FinOps Alliance. If you want to prevent losing oversight or getting caught in the details, partnering up with a FinOps specialist can save you a lot of headache. Cloudar is a very proud member of the FinOps Alliance. Be sure to contact us if you want to hear how we can help you optimize your cloud costs.

The post How the FinOps Shared Responsibility Model can help you optimize cloud costs appeared first on Cloudar.

The current FinOps philosophy is mainly dominated by the principles, phases and capabilities provided and described by the FinOps Foundation. For people looking to take their first steps into Cloud Financial Management, that is a solid place to start. In general, the FinOps Foundation (or F2) Framework provides a set of rules to keep in mind (the principles), a suggestion of phases to split your adoption in and a list of tasks that can give you an idea of the responsibilities for a FinOps team.

In tandem with the development of the F2 Framework, AWS started growing the cost-optimization pillar of their Well-Architected Framework into the AWS Cloud Financial Management framework. In it, they provide four pillars to structure your cloud financial practice. Where the F2 Framework preaches Inform, Optimize and Operate as key parts of the FinOps adoption journey, AWS tells you to build on the pillars of See, Save, Plan and Run.

After talking with people from both AWS and the FinOps Foundation, I think this is the best way to compare the two: The F2 Framework is a holistic, culture-focused approach that seeks to provide a frame of reference when implementing FinOps in your organization. The AWS Cloud Financial Management framework is more hands-on, more technical and strives to establish a practice within the existing company culture.

I’m sure that with the growth of FinOps in the tech landscape, new frameworks and ways of approaching Financial Operations in the Cloud will emerge. While it is always good to not have to start from scratch with something, we shouldn’t forget that FinOps happens in the field. If you Google “DevOps Principles”, you get one blog saying there are seven core principles, another saying there are three, and yet another claiming the real number is five. The truth is, DevOps (and likewise FinOps), is whatever you need and build in your own organization.

FinOps is at its core a grassroots practice that can be aided, but not dictated, by a framework. Do what works for your company, be inspired, change the principles, pillars and phases to terminology that works for you. The right approach is the one that helps you reach your FinOps goals. In the end, adopting FinOps is about internalizing FinOps in your organization, not about adopting a framework.

The post Do what works: choosing the right FinOps approach appeared first on Cloudar.