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.

Creating and managing secrets is perhaps as old as humans interacting with each other. Yet despite their critical importance, secrets remain one of the most vulnerable aspects of AWS infrastructure today. In our practice as Dev(Sec)Ops Engineers, we see these challenges daily accross our client environments.

To start, the question needs to be asked: “What exactly is a secret?”  In AWS and Cloud environments in general, a secret is anything used to access systems and/or data. These digital keys unlock potentially critical systems and must be protected from unauthorized access at all costs.

As Dev(Sec)Ops Engineers working in AWS, you are responsible for managing an extensive arry of secrets:

• RDS database usernames and passwords
• API keys for AWS services and third-party integrations
• CodeDeploy and deployment system credentials
• KMS encryption keys for data protection
• Private keys for SSL/TLS certificates and secure communications
• EC2 SSH keys and key pairs
• IAM user credentials for developers, QA, and operations teams
• Application service accounts and roles
• Any username/password combinations
• Sensitive configuration data that could aid attackers

The challenge is not just the volume … it’s the complexity of securing these secrets across multiple AWS accounts and other environments while maintaining operational efficiency.

The Hidden Dangers: How Secrets Get Compromised in AWS

 The Configuration File Trap

Storing secrets in configuration files is convenient but dangerous, especially in AWS environments where these files often end up in S3 buckets or EC2 instances. This risk was nicely illustrated in the RSA conference presentation “Red Team vs Blue Team on AWS” by Kolby Allen and Teri Radichel: Link to video

In the video Kolby deployed AWS resources using sample code found easily on the Internet.  Teri, simulating an attacker, conducted a penetration test and discovered a Lambda function’s configuration file stored in a S3 bucket (for convenience) complete with REDS database credentials in plain tekst.

If you must use configuration files in AWS:

• Maintain separate files for development, QA, and production AWS accounts
• NEVER commit these files to source control systems (GitHub, GitLab, Bitbucket)
• Use S3 bucket policies and encryption, but understand this is still suboptimal
• Consider AWS Systems Manager Parameter Store as a minimum improvement

This vulnerability is so important that it’s formally recognized in the MITRE attack framework:  [CWE-200: Exposure of Sensitive Information] (link)

Public Source Control: A Goldmine for AWS Account Takeovers

The most devastating secrets management failures occur when AWS credentials are committed to public repositories. The scale of this problem is staggering.

The people at TruffleHog constructed a live scanner for this:

https://forager.trufflesecurity.com/explore

This scanner continuously detects AWS access keys, secrets keys and other credentials in public Github commits, revealing the massive and constant stream of exposed AWS and other secrets.

This has a widespread impact: TruffleHog researchers discovered approximately 4,500 secrets among the top 1 million websites, many of which were AWS credentials, as detailed in their comprehensive analysis:

https://trufflesecurity.com/blog/4500-of-the-top-1-million-websites-leaked-source-code-secrets

Leaking these secrets can have far reaching financial consequences:

A Reddit user faced a 26.000 $ bill after IAM was compromised to execute crypto miners:

https://www.reddit.com/r/aws/comments/17p3v1e/account_got_hacked_and_get_26000k_bill/

A Developper was billed 14.000 $ on AWS following similar exposure:

https://dev.to/juanmanuelramallo/i-was-billed-for-14k-usd-on-amazon-web-services-17fn

AWS responded on these massive bills and is now actively scanning GitHub respositories through their AWS Credentials Exposed program and automatically disables discovery IAM access keys, but the frequency of these incidents remains alarmingly high as shown by the Trufflehog data.

Internal Systems: The False Security Blanket in AWS

Private repositories and internal systems create a dangerous illusion of security, even within AWS environments. The 2020 Twitter breach perfectly illustrates this vulnerability:

Attackers breached the perimeter, accessed internal Slack channels where developers had stored AWS credentials and other secrets, and used these to compromise infrastructure in a widely publicized incident:

https://www.zdnet.com/article/twitter-says-hackers-accessed-dms-for-36-users-in-last-weeks-hack

Secrets embedded in code even in fully private AWS services, proliferate across AWS services and do appear in:

• CloudWatch logs from Lambda functions and EC2 instances
• S3 bucket access logs
• CloudTrail event data
• Application Load Balancer logs
• Systems Manager Session Manager history

As such they do create additional attack vectors within your AWS environment.

Runtime Exposure: Secrets in AWS Production Workloads

Running AWS applications create numerous opportunities for secret exposure:

• Configuration files within EC2 instances or container images
• Environment variables visible in ECS task definitions or Lambda configurations
• Memory dumps from EC2 instances containing sensitive data
• Application caches in ElastiCache storing credentials
• CloudWatch logs revealing secrets in error messages
• EC2 instance metadata (IMDSv1) exposing IAM credentials
• Unencrypted S3 bucket metadata and tags
• AWS CloudShell command history
• Bash history on EC2 instances
• Container image layers in ECR with embedded secrets

This non-exhaustive list demonstrates how secrets can leak from multiple AWS vectors without proper handling.

What does AWS offer to fight this battle ? AWS Native Secrets Management

Adopt Just-in-Time Secret Retrieval with AWS Services

Core Principle: Store secrets in AWS-native management systems and retrieve them only when needed.

Instead of embedding secrets in configuration files, implement this AWS-secure workflow:

1. Store secrets in AWS Secrets Manager or Systems Manager Parameter Store
2. Retrieve secrets programmatically using AWS SDKs at runtime
3. Use IAM roles and policies for access control
4. Clear secrets from memory when no longer needed

AWS Access Control: Implement least-privilege IAM principles

• Developers cannot access production secrets via IAM policies
• Applications use IAM roles to retrieve only their required secrets
• Cross-account access is controlled via resource-based policies

AWS-Native Secrets Management Solutions

• AWS Systems Manager Parameter Store
• AWS Secrets Manager (Recommended for Production)

As an MSSP, we recommend AWS Secrets Manager as the gold standard for AWS environments.

Why Secrets Manager over Parameter Store?

• Enhanced security controls with fine-grained IAM integration
• Automatic secret rotation for RDS, DocumentDB, and Redshift
• Cross-account access capabilities essential for multi-account AWS strategies
• Comprehensive audit trails via CloudTrail integration
• No CloudFormation exposure risks unlike Parameter Store
• Encryption at rest using AWS KMS by default

As such we recommend the AWS Secrets Manager for Production workloads, the Encrypted Parameter Store can be used as a configuration store to fetch certain parameters.

How to use this in code ?

Python with boto3:

import boto3
import json

# Using IAM role-based authentication (recommended)
client = boto3.client('secretsmanager', region_name='us-east-1')

try:
    secret_response = client.get_secret_value(SecretId='prod/rds/mysql-credentials')
    secret_dict = json.loads(secret_response['SecretString'])
    
    # Use the secret
    db_username = secret_dict['username']
    db_password = secret_dict['password']
    
except ClientError as e:
    # Handle AWS-specific errors
    if e.response['Error']['Code'] == 'DecryptionFailureException':
        # Secrets Manager can't decrypt the protected secret text using the provided KMS key
        raise e
    elif e.response['Error']['Code'] == 'InternalServiceErrorException':
        # An error occurred on the server side
        raise e
    elif e.response['Error']['Code'] == 'InvalidParameterException':
        # Invalid parameter value
        raise e
    elif e.response['Error']['Code'] == 'InvalidRequestException':
        # Parameter value is not valid for the current state of the resource
        raise e
    elif e.response['Error']['Code'] == 'ResourceNotFoundException':
        # Can't find the resource that you asked for
        raise e

Via Infrastructure as Code:

• Cloudformation:
  • https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-secretsmanager-secret.html
• Terraform:
  • https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-sensitive-data-secrets-manager-terraform/using-secrets-manager-and-terraform.html
• AWS CDK:
  • https://docs.aws.amazon.com/secretsmanager/latest/userguide/cdk.html
• Pulumi:
  • https://www.pulumi.com/registry/packages/aws/api-docs/secretsmanager/secret/

AWS Key Management Service (KMS)

AWS KMS provides dedicated encryption key management, solving the “where to store the encryption key” problem for AWS environments. KMS integrates seamlessly with Secrets Manager and most AWS services.

KMS Best Practices for Secrets:

• Use customer-managed KMS keys for production secrets
• Implement key rotation policies
• Use separate KMS keys per environment/account
• Leverage KMS key policies for fine-grained access control

AWS Systems Manager Parameter Store

While we recommend Secrets Manager for sensitive data, **Parameter Store** works well for:

• Non-sensitive configuration data
• Cost-conscious environments (free tier available)
• Simple use cases without rotation requirements

Multi-Account AWS Strategies

For AWS Organizations with multiple accounts (our recommended approach), consider:

Cross-Account Secrets Access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::PROD-ACCOUNT-ID:role/ApplicationRole"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "secretsmanager:ResourceTag/Environment": "production"
        }
      }
    }
  ]
}

Multi-Region Considerations:

• Replicate critical secrets across AWS regions
• Use AWS Secrets Manager automatic replication
• Consider data residency requirements

AWS Implementation Best Practices from Our MSSP Experience

Security Architecture Considerations

• Design secure AWS deployment pipelines** using CodePipeline, CodeBuild, Github Actions with ci-cd plugins like trufflehog : https://undercodetesting.com/how-to-hunt-for-sensitive-credentials-using-trufflehog
• Implement comprehensive IAM access management with least-privilege principles
• Establish governance policies using AWS Config and AWS Organizations SCPs/RCPs
• Plan for secret rotation using AWS Secrets Manager automation
• Monitor and audit secret access via CloudTrail and CloudWatch

Operational Excellence in AWS

• Automate secret provisioning using AWS Lambda and CloudFormation/Terraform/…
• Implement emergency access procedures via AWS SSO and break-glass roles
• Establish incident response for compromised secrets using AWS Security Hub or other CSPM/CNAPP
• Regular security assessments using AWS Inspector and third-party tools
• Cost optimization by right-sizing Secrets Manager usage vs. Parameter Store

AWS-Specific Monitoring and Alerting

Set up CloudWatch alarms for:

• Unusual Secrets Manager API calls
• Failed secret retrievals
• Cross-account secret access
• KMS key usage anomalies

Conclusion

Effective AWS secrets management is not just about choosing the right AWS service it’s about implementing a comprehensive security strategy that leverages AWS-native capabilities while addressing the entire lifecycle of sensitive data. The examples and breaches discussed here represent real financial and reputational risks that AWS customers face daily.

Key AWS Takeaways:

1. Never store secrets in configuration files, S3 buckets, or source control
2. Use AWS Secrets Manager for production secrets management
3. Implement just-in-time secret retrieval with AWS SDKs
4. Apply least-privilege IAM policies and roles
5. Leverage AWS KMS for encryption key management
6. Plan for multi-account and multi-region secret strategies

The post AWS Secrets Management: Protecting Your Digital Keys in the Cloud 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.

Interestingly, Roles Anywhere does not completely solve the problem of not needing to create long-lived credentials, instead it moves (and reduces) the problem from credential management (rotation) to certificate management (distribution).

Setting up a Certificate Authority (CA) that can create certificates can be done with AWS Private Certificate Authority, and there are some options out there to manage distribution (usually as part of a bigger Device Management solution), but wouldn’t it be nice if the government of Belgium would do that for us?

The Belgian eID

In Belgium every citizens gets an identity card. The government makes sure that these get distributed and renewed, and since 2005 they contain a chip that holds (among other things) a certificate that can be used for digital authentication. If we can tie this to Roles Anywhere, we don’t have to worry about certificate management ourselves.

This eID is the size of a bankcard and the chip can be interacted with using off the shelf smart card readers. Most information can be read without any additional authentication – if you have the correct middleware, but to sign something you need to enter a PIN code.

The different certificates

Every eID holds an “authentication certificate” that is tied to the owner of the eID and has been signed by the “Citizens CA”.  The Citizens CA’s certificate is in turn signed by the Belgium Root CA . The Root certificate is self-signed. If we trust the Belgium Root CA, we will be able to validate any authentication certificate. More information about this setup can be found at https://repository.eidpki.belgium.be/#/home

The authentication certificate has two pieces of information that are going to be useful to us:

• The Issuer, showing us that the certificate is indeed issued by the Citizen CA.
• The Subject, containing the name and National Number (a number that uniquely points to one person) of the owner.

AWS IAM Roles Anywhere

Roles Anywhere allows you to use a certificate and its private key to get temporary credentials. You can think of it as an AssumeRole call, but instead of starting from an Access Key, we start from a certificate.

There are a few components we need:

• Configuration in our AWS Account, to indicate which CA we trust, and which roles can be assumed by different Issuer and/or Subjects. This also includes the creation of IAM Roles.
• Software on our computer to interact with the Card Reader so we can prove we have access to the eID and know its PIN.

For our use case we are going to trust the Belgium Root CA, and create a Role that can be assumed with any certificate issued by the Citizen CA. We will than limit the permissions of that IAM Role, so it can only write to a unique prefix in S3.

We can do that because every component of the Subject in our certificate gets mapped to a principal tag on the role session. E.g. if the subject is “C=BE, SN=Doe, GN=John, serialNumber=70010112345, CN=John Doe (Authentication)”, we have the following principal tags, and we can use principal tags in any policy.

• x509Subject/C: BE
• x509Subject/SN: Doe
• x509Subject/GN: John
• x509Subject/serialNumber: 70010112345
• x509Subject/CN: John Doe (Authentication)

Putting it all together

In our AWS Account

We will create the following resources in our AWS Account:

• An S3 Bucket
• A trust anchor, configured to trust the Belgium Root CA certificate that is publicly available via https://crt.eidpki.belgium.be/eid/brca6.crt.  This way we can use any certificate created by the Root CA of any of its subordinate CAs (like the Citizen CA)
• An IAM Role, where we configure the trust policy to only allow usage of the Role if:
  • The principal is the Roles Anywhere service (rolesanywhere.amazonaws.com)
  • The Issuer is Citizen CA (aws:PrincipalTag/x509Issuer/CN must equal “Citizen CA”)
  • The source is our trust anchor (aws:SourceArn equals the ARN of the Root CA trust anchor)
• An IAM Policy on this role that allows PutObject acces to all objects that start with the unique National Number (aws:PrincipalTag/x509Subject/serialNumber)
• a (Roles Anywhere) profile that ties the trust anchor to the Role. We could configure more settings here, like a mapping of fields from the certificate or a session policy, but don’t need to.

Of course we do not have to do this by hand, we create a CloudFormation template for this. It can be found in our sample repository: https://github.com/WeAreCloudar/cloudformation-samples/tree/main/templates/roles-anywhere-eid

On our machine

On our machine, we will need – besides the eID and its PIN (at least on macOS, where I tested this):

• a SmartCard Reader
• the Roles Anywhere Credential Helper (downloadable from the AWS Website)
• The AWS CLI (or any other tool we want to use with our AWS Credentials)

We also need a few pieces of information:

• The ARNs of the trust anchor, profile and role we created
• Our own National Number and the name of the bucket (to test our policy)

Ideally we’d be able to configure the credential helper to read any eID we insert, and this is possible if you install the Belgian eID Middleware using the following command.

aws_signing_helper credential-process \
 --trust-anchor-arn $trust_anchor_arn \
--profile-arn $profile_arn \
--role-arn $role_arn \
--certificate "pkcs11:model=Belgium%20eID;object=Authentication" \
--pkcs11-lib '/Library/Belgium Identity Card/Pkcs11/beid-pkcs11.bundle/Contents/MacOS/libbeidpkcs11.dylib

However because of an issue with the helper, this only works on macOS if you build the helper yourself from source. Since we do not want to do that, we can plug in our eID and find and identifier using “aws_signing_helper read-certificate-data”. You should get something like

Matching identities
1) bf013dd57aa34f8f9d4e22ab89dd8eb2 "SERIALNUMBER=70010112345,CN=John Doe (Authentication),C=BE,..."
2) 786f7572198a4a8a82ee7ef3f205d7be "SERIALNUMBER=70010112345,CN=John Doe (Signature),C=BE,..."


Copying everything between quotes, allows us to create a new file, selector.json that looks like this:


[
{
"Key": "x509Subject",
"Value": "SERIALNUMBER=70010112345,CN=John Doe (Authentication),C=BE,..."
}
]

and use that to select our specific certificate:

aws_signing_helper credential-process \
 --trust-anchor-arn $trust_anchor_arn \
--profile-arn $profile_arn \
--role-arn $role_arn \
--cert-selector file://selector.json

Our smart card reader will now prompt us for a PIN. If we enter the right one, we get credentials as output:

{"Version":1,"AccessKeyId":"ASIA...","SecretAccessKey":"COA...","SessionToken":"IQoJ...","Expiration":"2025-03-28T14:16:07Z"}


We can put this command in our ~/.aws/config file, so the AWS CLI will execute it for us, but for testing purposes it’s slightly easier to use the “serve” option.  The AWS Documentation has a longer explanation about how you can use the credential-process: https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html#credential-helper-examples

Testing with s3

In one terminal we can run a credential / metadata server that can be used by the AWS CLI:

~$ aws_signing_helper serve -process \
 --trust-anchor-arn $trust_anchor_arn \
--profile-arn $profile_arn \
--role-arn $role_arn \
--cert-selector file://selector.json


This gives us
2025/03/28 14:28:12 Local server started on port: 9911
2025/03/28 14:28:12 Make it available to the sdk by running:
2025/03/28 14:28:12 export AWS_EC2_METADATA_SERVICE_ENDPOINT=http://127.0.0.1:9911/

We can than use a second terminal to run:

AWS_EC2_METADATA_SERVICE_ENDPOINT=http://127.0.0.1:9911/ aws s3 cp example_file s3://$bucket/serialNumber/70010112345/example_file

and get our file in s3:

upload: example_file to s3://.../serialNumber/70010112345/example_file

Conclusion

This experiment shows that being able to use an external device withIAM Roles, is a very powerful feature, because it can remove a lot of tasks related to certificate and credential management. Being able to do this with something I had in my backpocket made it extra cool.

However, the Belgian eID is probably not the best way to go about this in a real scenario:

• I just gave everyone living in Belgium access to my S3 Bucket. I could use a more scoped-down trust policy, but I would eventually run into limitations of trust-policy size.
• I also didn’t tackle Certificate Revocation Lists (CRL). Every time someone loses their wallet, I would need to invalidate certain certificates – this also runs into size limitations
• I already have a good way to give users access to AWS Accounts, using Identity Center or Cognito.
• The pkcs11 support on macOS seems limited, and I would have to install the middleware everywhere,

This does not mean that Roles Anywhere is not a good solution for this kind of cases:

• If you are already putting certificates on machines (e.g using an MDM solution), AWS IAM Roles Anywhere is a great fit
• Instead of relying on the Belgian Government you can buy an hardware key like a yubikey and use it as your certificate source. This is as secure as using the eID (only the machine with the key plugged in will be able to request credentials), and you would be limiting it to the exact serial number(s) in your trust policy anyway – making CRLs mostly moot.

The post Sign in with your eID: Using AWS IAM Roles Anywhere with a SmartCard Reader appeared first on Cloudar.

We’re proud to share some exciting news: Cloudar has achieved the AWS Small and Medium Business (SMB) Competency—a recognition that highlights our deep expertise in helping SMBs leverage the power of AWS to grow, innovate, and compete in today’s fast-moving digital world.

For many small and medium-sized businesses, the cloud represents both an opportunity and a challenge. Limited resources, time constraints, and evolving customer demands make it critical to choose the right technology partner. That’s where we come in.

At Cloudar, we’ve built our reputation by delivering tailor-made, cost-effective, and scalable AWS solutions—with a strong focus on simplicity, security, and performance. Whether you’re a fast-growing startup or a well-established company looking to modernize, our local team of AWS-certified experts is here to guide you every step of the way.

Why This Competency Matters for You

Earning the AWS SMB Competency is more than just a badge. It confirms that Cloudar has a proven track record of helping SMBs:

• Optimize their IT infrastructure for flexibility and agility

• Reduce costs by leveraging right-sized cloud architectures

• Improve security and compliance, without the need for complex in-house solutions

• Scale operations efficiently as business needs evolve

Our customer-centric approach means we take the time to understand your business goals, not just your technical requirements. From initial strategy to hands-on implementation and ongoing support, we become a true extension of your team.

Real Results for Real Businesses

We’ve helped dozens of SMBs in the Benelux and beyond to transform their operations with AWS. From e-commerce platforms and SaaS providers to manufacturing and logistics companies, our clients trust us to deliver cloud environments that work—today and tomorrow.

Curious how we can support your journey? Take a look at some of the solutions we’ve delivered and the value they’ve created:

https://cloudar.be/services-solutions/services-for-small-and-medium-businesses/

The post Cloudar Achieves AWS SMB Competency appeared first on Cloudar.

Cloudar, an AWS Premier Consulting Partner in Belgium, is expanding beyond its borders after more than a decade. A new location in Utrecht will facilitate further growth in the Netherlands. We discuss Cloudar’s plans with Steyn Huizinga.

Steyn Huizinga, Managing Partner at Cloudar NL, is leading the company’s Dutch expansion efforts. With ten years of AWS expertise, he brings the necessary experience to develop this new market. Cloudar was founded in 2014 and has always had a strong focus on AWS, a defining characteristic that sets it apart from other cloud specialists in both Belgium and the Netherlands.

Smart in Belgium and the Netherlands

While Cloudar has primarily focused on Belgian customers in the past, it has always operated beyond the border, Huizinga explains. “After a delay due to COVID, now is the right time to open a dedicated Dutch office, allowing us to fully concentrate on the Dutch market.” According to Huizinga, it is important that Cloudar is not just seen as “those smart guys from Belgium,” but rather as “those smart guys from Belgium and the Netherlands.” The Belgian team will continue focusing on its home market, while the Dutch team will be dedicated to local customers.

The growth ambitions for the Netherlands are significant. “We aim to attract around ten new colleagues by the end of 2025, with plans for even stronger growth in the second year to meet demand,” says Huizinga. That demand is particularly high in Azure-dominated Netherlands, he notes.

AWS Premier Consulting Partner

Achieving AWS Premier Consulting Partner status is no small feat. With only a few hundred partners worldwide holding this title, Cloudar is part of an exclusive group. Maintaining this status requires complete dedication to AWS, with stringent certification requirements for a significant portion of the workforce. Cloudar successfully meets these requirements with a relatively compact team, allowing it to be mentioned alongside much larger market players.

Cloudar’s AWS expertise is demonstrated through six AWS Competencies and five Service Validations across various domains. Given the vastness of the AWS portfolio, excelling in all services is impossible. Instead, Cloudar specializes in five core areas: security, cloud-native development, containerization, FinOps, and AI technology.

A key part of Cloudar’s approach is balancing innovation with responsible cloud usage. Many organizations start enthusiastically with AWS but later face unexpectedly high costs or overlooked security requirements. Cloudar advocates a ‘job-zero’ approach, integrating security and FinOps from the outset to prevent unpleasant surprises down the line.

By focusing exclusively on AWS, Cloudar stays close to the source of innovation. The company gains early access to AWS roadmaps, allowing it to anticipate new developments. This position in the AWS ecosystem enables Cloudar to respond quickly to changes and advise customers on the most effective implementations. For example, a container workload can be deployed in seventeen different ways on AWS, and Cloudar helps determine the optimal approach for each specific case. However, AWS can still surprise everyone, so consultants must be well-versed in the existing offerings.

In 2024, Cloudar achieved the AWS Sovereign Cloud Competency, aligning with the growing need for cloud sovereignty. The company embraces the mantra “encrypt everything” to ensure maximum data security. Additionally, Cloudar leverages AWS to approach IoT data in a more human-centric way rather than solely relying on dashboards.

Different Customer Preferences

Huizinga notes clear differences in cloud preferences among customer segments: “ISVs often prefer to run their IT on AWS, while enterprise customers typically adopt a multicloud approach.” In such cases, Cloudar collaborates with Azure-focused colleagues, ensuring that Cloudar’s expertise remains dedicated to the AWS portion of a customer’s cloud strategy.

Choosing between cloud providers can be complex and should always be based on a clear cloud strategy, Huizinga emphasizes. “Organizations need to determine why they use Cloud X or Y for specific situations.” This is particularly important when internal IT operations run on Azure, while customer-facing platforms such as websites or retail environments operate on AWS. “You don’t want data to be transferred unnecessarily between different clouds.”

Dutch Customers Already on Board

For Cloudar, expanding into the Netherlands is a natural step in its growth journey. The company already serves several Dutch clients, including Coop, Mediahuis (operating in both Belgium and the Netherlands), and RGF, an HR service provider. “Our approach is focused on helping organizations leverage Amazon’s cutting-edge technologies for competitive advantage while maintaining the fundamental aspects of a solid cloud infrastructure,” says Huizinga.

Huizinga observes that many companies adopt a multicloud strategy, with Microsoft Azure commonly used for office applications. AWS is frequently the preferred choice for customer-facing platforms, portals, and digital initiatives. “Of course, this is the perspective we see from our AWS-focused standpoint,” he adds.

According to Huizinga, AWS’s ‘model freedom’ philosophy provides a key advantage, particularly in AI. “AWS aims to offer customers as many AI options as possible, giving organizations the flexibility to choose the best solution for their specific needs.”

The post Cloudar Reaches a New Milestone with Dutch Expansion 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.

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

About the AWS Global Security & Compliance Acceleration Program

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

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

Enhanced security posture

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

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

Regulatory compliance

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

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

Faster time-to-market:

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

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

Cloudar helps you leverage the power of AWS Security

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

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

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

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

The Cloudar Difference

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

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

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

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

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

December 4, 2024 – Cloudar, AWS Premier Consulting Partner and Managed Services Provider, announced today that they have achieved the Amazon Web Services (AWS) Digital Sovereignty Competency status. This specialization recognizes Cloudar as an AWS Partner that helps customers and the AWS Partner Network (APN) address customers’ digital sovereignty requirements while leveraging the power of AWS.

Achieving the AWS Digital Sovereignty Competency differentiates Cloudar as an AWS Partner that has demonstrated technical proficiency and proven customer success supporting the assured control and authority over data and infrastructure in the digital domain, including residency control, access control, resilience, survivability, and self-sufficiency. Cloudar is equipped to advise and architect for their customers’ sovereignty needs while leveraging AWS technology.

“Cloudar is incredibly proud to have earned the AWS Digital Sovereignty Competency” said Bart van Hecke, Co-Founder of Cloudar. “It reinforces our dedication to delivering secure, local cloud solutions that prioritize our clients’ data sovereignty and compliance needs.” 

Cloudar has helped customers like VDAB, the Flemish public employment service, meet their governance requirements through the implementation of a landing zone build on top of AWS Control Tower and AWS Identity Center. By leveraging these AWS solutions, VDAB can achieve compliance with EU data residency requirements and GDPR regulations, with all data securely encrypted using Customer Managed Keys. Cloudar’s solutions provide real-time compliance monitoring and automated controls, allowing VDAB to maintain operational efficiency while safeguarding sensitive public sector data.

AWS is enabling scalable, flexible, and cost-effective solutions from startups to global enterprises. To support the seamless integration and deployment of these solutions, the AWS Competency Program helps customers identify AWS Partners with deep industry experience and expertise across industries, use cases, and workloads to help grow their business.

About Cloudar

Cloudar is an Amazon Web Services (AWS) Premier Consulting Partner and Managed Services Provider with a 100% focus on AWS. They specialize in designing, building, and managing AWS infrastructure for businesses across a range of industries. With a deep commitment to innovation and security, Cloudar helps organizations fully leverage the power of the AWS cloud, providing tailor-made solutions for high availability, scalability, and cost efficiency.

As a trusted AWS partner, Cloudar offers end-to-end cloud solutions, from migration to continuous management and improvement, allowing businesses to focus on their core activities while Cloudar handles the complexity of the cloud.

Whether you’re looking to modernize your infrastructure, enhance your security posture, or accelerate your digital transformation journey, Cloudar is there to guide you every step of the way.

The post Cloudar Achieves the AWS Digital Sovereignty Competency appeared first on Cloudar.

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

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

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

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

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

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

Taking it Further: Imagine a Chatbot for Music Festivals

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

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

Here’s what this Music Festival Chatbot could do:

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

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

Why Build a Chatbot?

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

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

Let’s Connect in Las Vegas!

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

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