Cloud Consulting

When you need a cloud consultant

Companies usually contact me for one of these three reasons:

• Costs out of control, and nobody can say exactly where the money is going.
• A provider has to be chosen, or a decision made about staying on the current one, and the choice will weigh for years.
• There is a migration to do: to the cloud, from one provider to another, or partly out of the cloud.

Often the starting point is a review of the infrastructure that is already there: what it costs, where the risks are, what is worth changing first.

Cloud architecture and infrastructure

My experience in datacenters and on the cloud lets me take on migrations of every kind: from on-premise to the cloud, from one cloud provider to another, towards hybrid or multi-cloud setups, or in the opposite direction, from the cloud to bare metal. The direction changes, the way of working stays the same.

In hybrid and multi-cloud setups, before anything else, two things are needed: a complete networking plan, explaining how the different environments talk to each other, and high availability and disaster recovery plans, spelling out what happens when a piece goes missing. Without these two elements you add complexity without getting the benefits you expected.

Good practices, Infrastructure as Code and Kubernetes make it possible to design with the right degree of independence from the cloud provider: not a total abstraction, expensive and often useless, but enough freedom to adopt hybrid setups and migrate when needed.

This is less and less a theoretical matter. At a time when compute capacity is scarce, starting with GPUs, being able to move a workload to where the capacity is, or where it costs less, is a concrete advantage.

On hybrid and multi-cloud I have just one rule: keep complexity in check. You add a second provider, or an on-premise piece, when there is a concrete reason (costs, capacity, data constraints), not on principle.

Security and compliance are part of the design from the start: identity and permission management, network segmentation, secrets management, backup and disaster recovery, data residency (region choice and data paths kept within the EU where the GDPR or the industry requires it). I have handled the technical side of ISO 27001 certification paths, and I know what it means to turn requirements into verifiable configurations.

Cloud migration

When a migration fails, it is rarely the technology's fault. More often it is the way it is managed: all the risk concentrated in the cutover, little visibility into the operational details, and a team that ends up having to put its hands on systems it did not build.

We design and carry out the migration together, in Infrastructure as Code: every step is automated, traceable and reversible.

1. Analysis. What is there today, how it really works, where the dependencies and the risks are.
2. Strategy. What to migrate, in what order, to where, and what is better left where it is.
3. Incremental implementation. Services move one step at a time, each with its own rollback plan, instead of concentrating all the risk in a single cutover.
4. Follow-through. Once the migration is complete I stay on the project until the new infrastructure is stable and the team runs it on its own.

The team at the center of the migration

The internal team sits at the center of the migration. It has to own the change and lead it, not watch from the sidelines: a migration decided and carried out only from the outside does not last, does not stay stable and over time becomes hard to manage.

That is why the team takes part in the decisions, works on the implementation alongside me and, at the end, the new infrastructure is theirs.

Cloud repatriation: when it makes sense to go back

Not everything has to live in the public cloud. Bringing some workloads back on-premise or onto bare metal makes sense when they are stable and predictable, when cloud costs grow faster than the value they bring, or when you need resources, such as GPUs, that the cloud struggles to guarantee. It makes less sense for highly variable workloads, or when the team does not have the skills to manage the hardware.

Often the best solution is hybrid: every workload where it performs best. And the Infrastructure as Code approach means that this choice, too, stays reversible.

Cloud costs under control

Cutting cloud spend is often the first concrete result of working together. In the cases I have worked on the savings were between 20 and 40 percent, and the work paid for itself within a few months.

Most of it comes from three things: sizing resources correctly (rightsizing), since they are almost always bigger than necessary; removing what is no longer needed, such as forgotten environments, orphaned volumes and services that were never switched off; and optimizing network traffic, which on the cloud can have a significant impact.

AWS and Google Cloud

I have extensive experience on AWS and Google Cloud, on containers and Kubernetes, both in the managed versions (EKS, GKE) and self-installed and self-managed, and on on-premise infrastructure based on virtual machines. Among recent projects: a multi-cloud and edge platform on AWS, Google Cloud and Proxmox for a deep-tech startup, with GPU access and costs under control, and an open source observability platform distributed across owned datacenters and cloud providers.

AWS consulting

On AWS I work mainly on networking, account organization with AWS Organizations, multi-tenancy and isolation between environments and customers, containers with EKS and ECS, infrastructure for AI workloads, and Infrastructure as Code with Terraform.

The role of AI

AI now plays a central role in infrastructure management: language models know Infrastructure as Code well and are effective at debugging. AI-assisted analysis helps surface infrastructure drift, hidden dependencies and risks even before the migration begins.

It works on one condition, though: the agents have to operate inside a complete harness, that is, with the right context, tools and way of working (the infrastructure repository, the documentation, the ability to run a terraform plan and the tests, to propose changes through pull requests), with guardrails that define what they can do and with clear operating procedures on how things proceed and who approves.

How I work

It always starts with a review of what is there: architecture, costs, risks, dependencies. From there, the shape of the engagement depends on the problem.

• Single session. An architecture review, a second opinion on provider selection, a cost reduction plan.
• Project. A migration, a reorganization of accounts and networking, a cost intervention with measurable goals.
• Fractional engagement. Ongoing work alongside the team that runs the cloud infrastructure, when senior experience is needed but not a full-time hire.

In every case the internal team takes part in the decisions and the implementation: in the end, the infrastructure is theirs.