Cloud infrastructure: the foundation for all your projects

A website, then a CRM, then a few automations, then a first AI assistant. If each project arrives with its own access, its own hosting and its own bill, after a few years nobody knows who holds which keys, which data is backed up, or why the bill has gone up. A cloud infrastructure is built the other way round: a common foundation first, on which each project then lands.

This guide, from our Infrastructure and cloud section, explains what this foundation contains, where to put it, what it costs and what keeps it standing over time. If your tools live today in subscriptions that you would like to take back in hand, our Leaving SaaS offer puts this foundation on a server of your own, with tested backups and documentation included.

What is a cloud infrastructure foundation?

The three big providers have a name for it. In its guide to designing landing zones, Google Cloud describes it as “a modular and scalable configuration” that lets an organisation adopt its cloud, also calls it a “cloud foundation”, and adds that it is “often a prerequisite” to deploying a company’s workloads. AWS, in the “Landing zone” page of its migration guide, presents it as a baseline to get started with a multi-account architecture, identity and access management, governance, data security, network design and logging. Microsoft, in its presentation of the Azure landing zone, distinguishes the platform zone, “the centralized foundation that establishes governance, security, and shared resources for all your Azure workloads”, from the zones where teams deploy their projects.

The word comes from the big providers, but the question does not belong to them: on a dedicated server or a VPS, you also have to decide who has access, where the backups go and who is told about an outage. So we talk about a foundation, wherever it is put.

What does a landing zone contain?

Google lists four elements that a landing zone requires you to design: identity provisioning, resource hierarchy, network and security controls. It adds others depending on the company’s needs, including monitoring and logging, backup and disaster recovery strategy, compliance and cost control. For an SME, this gives the following.

Infrastructure as code describes the foundation in files instead of clicking it together in a console. Google recommends it, with Terraform for example, because it makes deployment “repeatable and modular”: the day you have to rebuild or move elsewhere, the recipe exists. Documentation, for its part, appears in no diagram, but it is what allows someone other than its author to step in on a Sunday.

The vault, finally, does more than store secrets: properly connected, it lets your automations and your AI agents use a key without ever reading it. That is the subject of our article on the secrets vault.

Nothing forces you to put everything in place on day one. Google says so itself: the first iteration of a landing zone is often not the final version, and it advises centring the initial design on what the first projects need, then adding the rest later.

Why is the foundation the common denominator of your projects?

Take an SME of forty people, an example built for the occasion. Its website is hosted by the agency that made it, its CRM is a subscription, its automations run on an employee’s personal account, and an AI assistant has just been connected to another employee’s bank card. Nothing shocking, project by project. The day the first employee leaves, nobody knows which automations will stop, which keys they held, or where the CRM backups are, if there are any.

Each project has improvised the same answers: who has access, what is backed up, who pays and how much. The foundation answers once, and each project inherits the answer. Microsoft puts it in its own way: “each subscription and its Azure resources inherit the governance and security policies” set above them, and the landing zone takes in new technologies, AI included, “without requiring changes to the overall architecture”. The same text sets a healthy limit: centralise only what brings “clear governance, operational, or economic benefits across multiple workloads”. The foundation is not one more project: it is what your projects have in common, and nothing else.

This is how we work for our own tools.

Where to put your infrastructure: big provider, European cloud or dedicated server?

For a company’s cloud hosting, there are three families of options, which are not mutually exclusive.

• A big provider (AWS, Google Cloud, Microsoft Azure). A huge catalogue of services, a bill that follows usage. At AWS, the landing zone is created with the AWS Control Tower service or custom-built, and “each option requires a different level of AWS knowledge”. It is the right choice when your projects need these services and someone knows how to run them.
• A European cloud. In France, ANSSI (the national cybersecurity agency) qualifies certain offers under the name SecNumCloud. On its page on the cloud, it describes them as “trusted” offers whose use is “recommended for the protection of sensitive data”.
• A dedicated server or a VPS. A fixed, predictable cost, but operations that fall almost entirely to you: updates, backups, monitoring. It is our choice for our own tools.

To decide, four criteria:

1. The nature of the data. Health data, personal data in volume, trade secrets: they often decide the location before anything else.
2. The skills available. A big provider requires you to know its console, its permissions and its billing; a server requires knowing how to maintain it. Choose what someone, in-house or at a service provider, will still be able to run in two years.
3. The cost over time. Compare over three years, operating hours included, not on the price of the first month.
4. Dependence on the provider. A foundation described in code, and data held in open formats, keep the way out open.

The question of sovereignty goes beyond this guide: we deal with it in our analysis of Europe’s dependence on the American cloud.

Nothing stops you combining them: your management tools on a server of your own, a compute-hungry project at a big provider. The foundation then remains a single set of rules, applied in both places.

How much does the foundation cost, and how do you avoid a surprise bill?

A foundation costs twice: at set-up, then every month in operation, and this second cost is counted mainly in hours. Google warns that designing and deploying a landing zone can take several weeks. To compare with your current subscriptions, our method is detailed in the real cost of leaving SaaS over three years.

With a big provider, the bill follows usage, and a forgotten resource keeps costing money. Google also lists tools to manage the internal distribution of costs among the reasons for setting up a landing zone before the first project. So set a budget per project and alerts from day one.

You still need to know what an alert does. Microsoft’s documentation on Azure budgets is clear: when a threshold is exceeded, “resources aren’t affected, and your consumption isn’t stopped”. The alert also arrives with a delay, and a drift on Monday may only be flagged on Tuesday.

To act automatically, you have to link the budget to an “action group”. Other providers have their own rules: read your own provider’s before relying on an alert.

The same reasoning applies outside the big clouds. On Palmora Property, a real estate portal that we operate, automations were running in a continuous integration service billed by the minute; after three nights with more than four hours of billed minutes each, we brought them back to a dedicated server. Conversely, some building blocks cost little: Palmora Property’s off-server backup plan comes to about $6 a month. What costs money is the hours spent on operations.

Why does operation matter more than installation?

A foundation does not break on the day it is installed. It degrades silently: a backup that fails, a certificate that expires, an update put off, an access never removed. Four routines make the difference.

• Backups actually restored. A backup that has never been restored remains a hypothesis. On Palmora Property, we judge a restoration by the number of tables and records recovered, not by the tool’s exit code, which reports an error on mere warnings. The detail is in our guide to backing up a server of your own.
• Monitoring that warns you. Google speaks of dashboards and alerts that notify you of “any actionable exceptions”. Someone still has to receive and read them.
• Planned updates, with a way of rolling back if one of them breaks a service. Our guide to self-hosted n8n in production shows this on a tool that changes almost every week.
• A written recovery plan. Google lists backup and disaster recovery strategy among the elements of a landing zone; for an SME, it is a page that says what to restart, in what order, and who to tell.

We speak from experience.

If you are starting from subscriptions, the order in which you bring them back onto your foundation also matters: we detail it in the tools to move off SaaS first.

What we offer, and what we can prove

Two cases, depending on the location chosen.

Your foundation on a server of your own. This is our Leaving SaaS offer: an audit of your subscriptions and their real cost over three years, up to five tools installed, your data migrated and verified, off-server backups with tested restoration, and operating documentation. It costs €5,500 and takes three weeks; managed services, as an option, cost €450 a month and cover monitoring, updates and tested backups.

Your foundation at a big provider or in a European cloud. We put it in place at the provider you have chosen, or that we choose together on the criteria above: account structure, identities and permissions, budgets and alerts, logs, backups, infrastructure described in code and documentation. Then we run it, or hand it over to you with its documentation.

What we can prove is our own foundation: a single server and a dozen services, with the trade-offs and incidents that this implies. We do not claim foundations already put in place at AWS, Google Cloud or Microsoft Azure. The three guides cited above show it: the building blocks of a foundation look alike from one provider to another, it is the tools that change. And if your project needs deep expertise in a provider that we do not have, we will tell you before we start.

Where to start

1. 01Take stock.

   The cloud accounts and subscriptions, who has administrator access, what data lives there, which bills arrive each month.

2. 02Sort your data.

   What is sensitive, what is not: this sorting often decides the location.

3. 03Put in place the day-one minimum.

   Named access with strong authentication, a budget and alerts, backups outside the main location with a tested restoration, and a page of documentation.

4. 04Bring in a first, low-criticality project.

   Google advises deploying first the workloads that run most easily on its cloud: it is on this first project that the foundation gets run in.

5. 05Add the rest as projects come along.

   Each new project checks that the foundation holds, and completes it if needed. To move what already runs without breaking anything, go workload by workload: we detail the method in Cloud migration: moving what exists without breaking everything.

If you want this foundation on a server of your own, our Leaving SaaS offer installs it in three weeks, with tested backups and documentation included. If it has to live at a big provider or in a European cloud, tell us about your projects and the provider you have in mind: we will tell you what your foundation needs to contain.

Frequently asked questions

Sources

1. Guide to designing landing zones (new tab)docs.cloud.google.com
2. The “Landing zone” page of its migration guide (new tab)docs.aws.amazon.com
3. Its presentation of the Azure landing zone (new tab)learn.microsoft.com
4. Its page on the cloud (new tab)cyber.gouv.fr
5. Microsoft’s documentation on Azure budgets (new tab)learn.microsoft.com