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.

Indirection

With Terraform […] no intermediary sits between you and the service you’re controlling. Want an RDS instance? Terraform will make calls directly to the RDS API.

First of all, both Terraform and CloudFormation provide some level of indirection. CloudFormation converts a YAML or JSON template to a set of API calls. Terraform does the same, starting from an HCL template.

Having that transformation in the cloud can make it harder to see the underlying API responses, but that’s not because of the conversion between template and API. The same APIs are still getting called, and they will raise the same errors when there is something wrong with the requests. If you look in CloudTrail, you will see these requests together with the entire error message.

The way CloudFormation implements that translation layer (for newer resources) can add a second step after an API call fails. However, it also allows for standardized errors in other cases, like “Resource Already Exists” or “Only configurable when creating a resource”.

The prerequisite steps you have to take to use CloudFormation [StackSets] across multiple accounts also must be taken just to have CloudFormation spin up resources in multiple regions within the same account.

I’d argue that StackSets (and Service Catalog) are benefits of using CloudFormation. However, if they are too much overhead for a project, you can still deploy to multiple regions by adding a –region parameter to your deployment command. Although, by not using StackSets, you’d lose some convenience features, like being able to update multiple regions in parallel easily.

Logic

Terraform offers a rich set of data sources and transforming data with Terraform is a breeze.

I agree that CloudFormation could use more intrinsic functions, but that does not mean it’s severely lacking in functionality. In many cases, you can replace the missing functions by being stricter about the acceptable inputs.

Speed

AWS CloudFormation is S-L-O-W.

CloudFormation can seem slow because it tries very hard not to get into a state where your infrastructure is broken. Both CloudFormation and Terraform try to execute as much in parallel as possible (keeping dependencies between resources in mind). However, CloudFormation will not start deleting resources until every creation and update has been completed. On top of that, CloudFormation will validate that all actions (deletes included) finish before it considers the deployment complete.

Sync vs Async

Wrapping CI/CD tooling around AWS CloudFormation is […] a difficult matter of polling stack updates until the right stack state bubbles up from an aws cloudformation CLI query.

Here Greg argues that Terraform is better because polling for changes can be challenging to do. However, if you’re okay with executing a command-line tool (like Terraform), you can AWS CloudFormation deploy, and the AWS CLI will do all that for you.

Even without the CLI, running async comes with some significant advantages:

• You don’t have to worry about the build tool (or your laptop) crashing or losing internet connectivity
• Everyone with access to the AWS account can see when an update is in progress and poll independently for changes
• You don’t need a process that keeps running during the change. The deployment will keep running until it’s done.

Running 100% as a managed service also includes the following advantages:

• You don’t need to execute any code on your machine
• You don’t need to worry about different tool versions and upgrades between them
• You don’t need an access key with full admin permissions
• You get state management included by default (instead of having to configure it yourself).

That safer approach has the potential of doubling the time it takes to execute a change (assuming that a create/update takes as long as a delete), but having automatic rollbacks is frequently worth the extra time.

Portability

If you learn AWS CloudFormation, then guess what: you can’t take your skills with you. If you put forth the effort to learn Terraform, then you can take your skills to any other cloud.

While the workflow might stay the same, the resources that you create are going to be vastly different between clouds. The primary skill that you should learn (independently from the tool) is how AWS works. This will make your skills transferable between tools instead of between clouds. You wouldn’t expect carpenters to list their experience with a hammer (even if it’s useful for all kinds of projects): instead you want to know what they can build.

Importing existing resources

I can’t even begin to tell you how to import resources with AWS CloudFormation, and neither can AWS’s engineers.

This is pure hyperbole. Importing resources into CloudFormation is documented, and the console has a basic wizard.

If we ignore the exaggeration, there is indeed still room for improvement. While all new resource types should support importing, there is still a long tail of old resources that are not yet supported. “All resources should support resource import” is a valid point. However, CloudFormation was usable before the introduction of this feature. Whether this is a dealbreaker will depend on how frequently you expect to import unsupported resources.

Service Quotas

The list of quotas for the AWS CloudFormation service is just hilarious.

I don’t think that documented limitations are necessarily a bad thing, and I wonder how many of those quotas people actually run into. It’s been a long time since I had to look at that page.

TL;DR

CloudFormation makes different trade-offs than Terraform. Looking at its sharp edges without considering the advantages they bring is unfair.

Use the tool that matches your requirements. If you want safe deployments, tight integration within AWS, and minimal operational overhead, CloudFormation will probably fit the bill.

The post #CloudartotheRescue: DO use AWS CloudFormation (a response) appeared first on Cloudar.

Getting around the Gateway

The API Gateway comes in four different flavors:

1. HTTP API
2. WebSocket API
3. REST API (public)
4. REST API (private)

One of the nice features you have with the API Gateway is that you can create a custom domain for the API Gateway (e.g., www.example.com). BUT there is a big catch to this: when you choose the private REST API flavor, you can’t use a custom domain name with your API Gateway. This means you end up with an AWS-provided domain name which is not user-friendly. For example, https://ab123456789.execute-api.eu-west-1.amazonaws.com/test (The format of the AWS provided domain name is: <API ID>.execute-api.<AWS Region>.amazonaws.com/<Stage Name>).

BUT have no fear: Cloudar is here!

We can bypass this limitation by utilizing an internal application load balancer in front of our API Gateway. This way the load balancer acts as our front door, giving us the ability to use custom domain names and forwarding all traffic to the API Gateway.

Important note: In this example we aren’t going to dive into the configuration of the API Gateway or the resources that are behind the API Gateway (Lambda, ECS, etc.), but rather the solution for using a custom domain name with your API Gateway.

The architectural design

The components that should already be in place are:

• A VPC with subnets
• Route53 private hosted zone
• A valid TLS certificate

The components we are going to create are:

• Internal Application Load balancer
• ALB Target group based on IPs
• VPC Endpoint for the API Gateway. (In our design we went with VPC Endpoint deployed in 2 AZs for high availability, but you it also works with 1 or 3 AZs)
• A private REST API Gateway

Configuring all the components

Route53

Create a Route53 private hosted zone and connect it to your VPC. This is the zone that is going to provide our custom domain name for our API Gateway. In our case the private hosted zone is called “cloudar.be”.

ACM Certificate

Via Amazon Certificate Manager (ACM) you can create or import a certificate to use with our Application load balancer. In our case, we created a certificate for “api.cloudar.be”.

VPC Endpoints for API Gateway

You can create the VPC Endpoints for API Gateway to ensure that you call the API using private IPs only. VPC Endpoints can be found under VPC >> Endpoints in the console. Under “AWS services”, search for “com.amazonaws.<your region>.execute-api”, select your VPC, select the subnets you want to deploy this, select the security group you want to couple with this endpoint and leave all the settings as is.

After the creation of your endpoint note, collect the following information that we are going to need later:

• The endpoint ID
• The IP addresses of the endpoints
• This can be found in the console under: VPC >> Endpoints >> select your endpoint >> Subnets tab

API Gateway

Next, we create our private REST API Gateway. Choose an API Name and a description. Endpoint Type should be set to “Private”, and under “VPC Endpoint IDs” you fill in the endpoint ID we created in the step above.

At this point your API should have been created. First thing we are going to do is add a resource policy to the API Gateway. This is mandatory, because otherwise we can’t deploy our API later.

For this demo, we are going to allow everyone who is in our network to call the API, but in real-life scenarios you can use a Condition to limit only traffic coming from certain IPs, VPC or VPC endpoint.

Don’t forget to save your resource policy!

After completing this, we can go ahead and create a GET method under “/” of the API Gateway. As “Integration type” we are going to choose “Mock” since this is just a tutorial to show you how to use custom domain names with a private API Gateway.

Now that we have a private REST API, with its resource policy allowing it to be invoked and a GET method, we can deploy this API to a stage. In our case we have a stage called “test” where we deployed this API to.

So by now you should have received your Amazon-provided domain name for your API Gateway in the following format:

https://<API ID>.execute-api.<AWS region>.amazonaws.com/<stage name>

This can be found/verified in the console under API Gateway >> API’s >> your API >> Stages >> select your stage. There at the top of the page, you can find your Amazon-provided domain name for that stage.

The only thing that remains is to map this API to a custom domain name. Open “Custom domain names” under the API Gateway section.

• Create a new custom domain name, in our case: api.cloudar.be
• Endpoint type: Regional
• ACM Certificate: Select the certificate you made for api.cloudar.be in ACM

After the creation of the custom domain name, we go to “API mappings” within the custom domain names screen and configure a new API mapping and save it by going to:

• API: Select the API you just created
• Stage: test

Application Load balancer & target group

To set up the load balancer, we start by creating a target group. This is a target group based on IPs of the API Gateway VPC Endpoints. In our case:

• Target type: IP addresses
• Target group name: api-endpoints
• Protocol: HTTPS
• VPC: Choose your VPC
• Health check protocol: HTTPS
• Under “Advanced health check settings” >> Success codes: 200,403
• Register the IP addresses of the API Gateway VPC endpoints on port 443 and create the target group. These IPs can be found under: VPC >> Endpoints >> select your endpoint >> Subnets tab

Now that we have our target group, we can create our Application load balancer:

• Load balancer name: private-api-loadbalancer
• Scheme: Internal
• Select your VPC, subnets and the security group for this load balancer
• Listener: HTTPS
• Default action: Forward to api-endpoints target group

Configuring the security groups

The last step is to finetune our security groups for the load balancer and the API Gateway endpoints.

Security Group VPC Endpoint

In the security group of the VPC Endpoint, we are going to add a rule that allows HTTPS traffic from the security group of the internal ALB (red underlined in example here below).

Security group application load balancer

This security group acts as our entry point when we call the API Gateway. Here you can allow traffic from your VPC CIDR range, on-premises range, only a certain IP or many more variations. In our case we are going to allow inbound on HTTPS from our VPC CIDR range.

Important note: Traffic can still be dropped if your API’s resource policy doesn’t have a valid allow statement. In our scenario we control the inbound traffic via the internal ALB’s security group. Our API’s resource policy is created in such a way that it accepts all traffic (see example API resource policy under API Gateway section).

The final step

Now you can deploy an EC2 instance in a subnet and make a call to: https://api.cloudar.be and getting forwarded to your private REST API Gateway.

And voilà! Now you can have your cake and eat it too with a custom-named API Gateway. Want to know what other AWS tricks we have  up our sleeves? Check out our blog or get in touch with us.

The post #CloudartotheRescue: How to use custom domain names on a private REST API Gateway appeared first on Cloudar.

One of the key take-aways, is to travel in good company. Good travelling buddies make you strong and resilient in order to overcome roadblocks. They make you persistent. I have had the joy and luck to travel in very good company the past few years.

Today is the day to stop at a Milestone and enjoy the scenery.

At Cloudar, we are glad to announce that we officially have achieved our AWS Migration Competency Delivery partnership.

With this competency, Cloudar has proven to be a reliable partner and expert for Customers to assist and guide them in their Digital Migration journey.

It will get its place besides all of the other AWS competencies we already achieved.

Look at it as climbing a mountain, you have to be well-prepared for it , and well-equipped. But it will still take quite some effort and make you sweat. But when you arrive at your goal, you will see the clear perspective of where you’re going to. New roads reveil.

Today, with this competency, and with strong support of AWS, we are ready to even help our customers even more with reaching their goals and become a trustworthy travel companion in their Digital Migration Journey.

Maybe the travel metaphor seems less relevant in these times of staycations, but it is the journey itself and your next target that counts. It doesn’t always need to be far, just enjoy the road and your next success.

So, I think we arrived at a conclusion : you now know that Cloudar is an AWS Migration delivery partner ready to roll, staycations can be quite enjoyable too, and I also believe we even have got the people, process, tooling triangle covered along the way…

Please allow me to say special thanks to the travel companions that made it happen : AWS & AWS Partner Migration team, Cloudar Teams and especially our Customers ! Thank you.

Please consult the Public Migration Customer cases on our website and reach out.

The post Great News : Cloudar is an official AWS Migration Competency Delivery Partner ! appeared first on Cloudar.

Unfortunately, the blog post did not include a list of changes. Luckily there are other places where you can find those changes (if you know where to look):

For the quick summary of the changes, you can head over to the AWS Architecture Blog: Announcing the New Version of the Well-Architected Framework.

To find more details, with some additional context about why they changed, you can check out a different blog post for each pillar:

• What’s New in the Well-Architected Operational Excellence Pillar? on the AWS Architecture Blog
• Updates to the security pillar of the AWS Well-Architected Framework on the AWS Security Blog
• What’s New in the Well-Architected Reliability Pillar? on the AWS Architecture Blog
• What’s New in the Well-Architected Performance Efficiency Pillar? on the AWS Architecture Blog
• What’s New in the AWS Well-Architected Cost Optimization Pillar on the AWS Cost Management Blog

If you want to see the actual changes, you would have to download both the old and the new PDF and put the questions side by side. And that’s exactly what we did. There is value in seeing the actual changes – even though the posts above already give a decent idea of what is different – but keep the following in mind when you look at the file we compiled:

• We only looked at the titles of the best practices. These aren’t the only improvements, there have been a lot of changes in the descriptions, examples, and explanations too.
• Since the attached document only shows the changes, it’s recommended to use it side-by-side with the official pdf.
• It’s not the prettiest looking document, but we hope it’s useful anyway.

That being said, we’re interested to hear what you think of these changes!

Download the list of changes here

The post The detailed updates to the Well-Architected Framework appeared first on Cloudar.