From AWS to Exoscale: A report on experiences

Cloud & DevOps

May 9, 2024

5/9/24

In this post, I share my experiences from migrating a software project from AWS to Exoscale. A look behind the scenes of an exciting cloud migration project.

In this post, I share my experiences from migrating a software project from AWS to Exoscale. A look behind the scenes of an exciting cloud migration project.

From AWS to Exoscale
From AWS to Exoscale
From AWS to Exoscale

In the world of cloud services, migration is often a huge undertaking, especially when an infrastructure has been built and grown with vendor-specific services. Each platform has its peculiarities and specific services that can be deeply integrated into applications. In the so-called Vendor Lock-in, a customer cannot easily replace a used service or product with an equivalent solution from another provider. This often makes migrating from one cloud provider to another a very time-consuming task because the product must first be reconfigured to be functional on other platforms. At agsolutions, we fundamentally pursue the approach of avoiding vendor-specific services whenever possible to steer clear of Vendor Lock-In.

Recently, we conducted the switch from AWS (Amazon Web Services) to Exoscale for a healthcare software we developed, gaining valuable insights and practical experience in the process. Since we have moved away from AWS-specific cloud services for our application, the migration from the ground up has proven to be less complex. In this article, I share these experiences and discuss the challenges, processes, and considerations necessary for a successful migration.

Why switch from AWS to Exoscale?

AWS is known as a global cloud giant and offers a wide range of services, but also with a relatively high level of price and complexity, which can often be overdimensioned for some SMEs. In contrast, Exoscale is a European provider that focuses on data protection, simplicity, and cost efficiency. Therefore, switching to Exoscale may be worthwhile for organizations looking for a leaner and GDPR-compliant cloud infrastructure.

Data stays in Austria

Exoscale, in addition to its European focus, also offers specific data centers in Austria, which provides significant advantages for local companies and organizations. The availability of Austrian zones enables a cloud infrastructure that is close to the organization, ensuring low latencies and high data availability. Particularly regarding the GDPR, Exoscale is an attractive choice, as compliance with data protection standards and compliance guidelines can be implemented more easily.

e-card connection

Furthermore, Exoscale supports the connection to the Austrian e-card network, which is crucial for institutions in the healthcare sector. This seamless connection enables secure and efficient communication with the cloud services of social insurance, facilitating and accelerating data exchange in healthcare.

Personal support

Another advantage of Exoscale is the personal support that stands directly by companies' sides. Instead of relying on anonymous support tickets and changing contacts, Exoscale offers dedicated experts who are specifically familiar with customer requirements. This significantly simplifies the solution process, as direct support is available for technical questions or challenges.

Selection of Exoscale services

Which AWS services do we use and what alternatives are available at Exoscale? The healthcare application relied on some AWS-specific services. Although Exoscale does not offer the same range of services, we were able to find alternative and even better solutions:

Beanstalk to Kubernetes

AWS Elastic Beanstalk was used before migration to automate the provision of entire environments for the application. Beanstalk managed EC2 instances, load balancers, networks, SSL certificates, and more.

We decided to replace Beanstalk with Kubernetes. However, running Kubernetes is not an easy undertaking, which is why we rely on Exoscale SKS, a fully managed Kubernetes service. With SKS, companies can quickly set up Kubernetes clusters without having to worry about the underlying infrastructure or the complex management of Kubernetes itself.

Container Registry

We did not need a container registry with AWS Beanstalk as the application was built and deployed directly from code. To provide Docker images for Kubernetes, we use the managed container registry from the Exoscale marketplace.

RDS to DBaaS

Replacing Amazon RDS for PostgreSQL was relatively simple, as Exoscale offers a managed database service DBaaS - Managed PostgreSQL.

S3 Storage

Exoscale offers an S3-compatible object storage, so the migration of our S3 data went smoothly overall.

DNS and Load Balancing

Instead of Route 53, we use Exoscale DNS and utilize managed load balancing services from Exoscale, which seamlessly integrate into the new infrastructure.

SES & SNS

We use Amazon's SES - Simple Email Service and SNS - Simple Notification Service for sending emails and SMS. There has been no change here with the switch to Exoscale. These two AWS services are still in operation since Exoscale (and, in my opinion, other providers as well) do not offer equivalent services. No personal or sensitive data is sent via email or SMS, so we decided to continue using these services.

Monitoring

For monitoring our hybrid cloud environment, which includes both AWS services (SNS and SES) and Exoscale, we rely on Datadog. This solution provides a central platform that seamlessly integrates AWS and Exoscale components, offering detailed metrics, logs, and alerts. Datadog simplifies the monitoring of hybrid environments, facilitates troubleshooting, and supports us in performance optimization. It is worth noting that no personal or sensitive data is transmitted to Datadog.

An alternative would be to implement a monitoring solution within our Kubernetes cluster, which is based on OpenTelemetry, Prometheus, Loki, Tempo, and Grafana. However, this approach requires the operation and maintenance of these tools independently. The decision for Datadog – or alternatively Dynatrace or Grafana Cloud – allows for quicker implementation and is less maintenance-intensive.

Zero Downtime

The migration of the PostgreSQL database from AWS RDS to Exoscale without downtime is possible via Logical Replication. Changes in the source database are replicated in real-time to the new Exoscale PostgreSQL instance. Once all data is synchronized, a planned, quick switch-over can occur at the time of the transition, allowing for practically non-disruptive migration. No additional tools are needed for the setup of replication, as Exoscale DBaaS offers this service by default, and it can be activated at any time.

Replication of the S3 data is somewhat more challenging. For this, for example, a cron job can be created in Kubernetes that synchronizes the buckets every few seconds using rclone.

Update from 01/06/2026:
Exoscale now offers Managed Bucket Replication. The implementation of a manual replication as described above is no longer necessary.

From Click Configuration to Code: IaC with Pulumi

Since the AWS infrastructure was initially created through the console UI, it lacked structure and clear version control. We used the migration to Exoscale as an opportunity to introduce Infrastructure as Code (IaC) with Pulumi. With Pulumi, we can define and manage the entire infrastructure – from network resources to databases – as code, bringing transparency, repeatability, and traceability to our environment. Pulumi also allows us to work in languages like TypeScript, which facilitates integration into existing development workflows. This way, we keep track of all resources, can automate changes, and have robust, versioned code that documents the infrastructure optimally.

Challenges and Lessons Learned

A migration of this scale always brings challenges, and here are some of the key learnings:

  • Planning is the alpha and omega: A detailed migration plan helped minimize unexpected problems and avoid downtime.

  • Backups: New backups and disaster recovery strategies were developed using Kubernetes cron jobs, as Exoscale currently does not offer managed backup solutions (like AWS Backup) for S3 data.

  • S3 Bucket Lifecycle Policy: As of now, Exoscale SOS does not support an automated bucket lifecycle policy. This functionality had to be manually mimicked with Kubernetes cron jobs.

  • Encryption: Objects in Exoscale SOS are stored unencrypted by default. As a solution, we implemented client-side encryption in the application, meaning objects are encrypted in our application before being transferred to SOS.

Update from 01/06/2026:
Exoscale now offers Encryption at rest with SSE-SOS. When enabled, Exoscale manages the automatic and fully managed encryption of the objects.

Conclusion

The migration of an entire service landscape from AWS to Exoscale was a challenge, but the benefits make the effort worthwhile: lower costs, European data protection standards, and server location in Austria. Every cloud migration carries risks and learning processes, but with careful planning and testing, we were able to complete the migration successfully and are now running the applications stably on Exoscale.

For companies searching for a cost-effective, data protection-friendly alternative to AWS, Exoscale could be an excellent choice. If you are looking for support or advice for your cloud projects, we are happy to assist you.

👉 Don’t hesitate to contact us!