Solutions

AWS migration with EU data residency built in

Move your workloads to AWS on a landing zone built with NTC, the Nuvibit Terraform Collection. EU residency, guardrails and compliance mapping are part of the foundation from the first commit, not a clean-up project after cutover.

Book a callContact us

What's included

Isometric illustration of a landing-zone platform surrounded by its deliverables: infrastructure code, a policy shield, a diagram and a runbook
  • Data residency assessment. Every workload, data store and third-party integration mapped against where it needs to live, so the plan rests on facts.
  • NTC landing zone. Terraform/OpenTofu on AWS Organizations, in Frankfurt and other EU regions, or in the European Sovereign Cloud where a workload needs it.
  • Policy-as-code guardrails. OPA validates every change against your residency and security standards before it lands.
  • Migration plan and cutover. A workload-by-workload sequence, including workloads from your current AWS landing zone.
  • C5 and GDPR mapping. Control mappings and data flow diagrams your legal and security teams can use for due diligence.
  • Handover. Runbooks, infrastructure code and pairing time, so running the environment does not depend on us.

Two ways to get there

Build the foundation yourself, or start from one that already works

Starting from scratch by yourself

  • You design account structure, guardrails and logging from a blank page.
  • Residency rules live in a wiki until someone turns them into code.
  • Every new account repeats the setup by hand or by script.
  • Audit evidence is collected after the fact.

With NTC and a guided migration

  • Versioned Terraform/OpenTofu modules for organization, accounts, security and network.
  • Residency is enforced by service control policies and OPA checks on every change.
  • New accounts come out of the account factory with the baseline applied.
  • Controls are code your auditors can read, and they stay current.

Why NTC

A landing zone your team can read, review and run

Infrastructure

Terraform or OpenTofu, not YAML

The landing zone is HCL built on NTC, so your team reviews and versions it with the tooling it already uses. GitHub Actions or Spacelift for example.

Architecture

AWS Organizations first

NTC builds on AWS Organizations directly, which allow more flexible and fine-grained account management. Control Tower is optional.

Governance

Policy as code with OPA

Open Policy Agent checks every infrastructure change against your standards before it is applied.

Compliance

C5 and GDPR mapped in

BSI C5 hardening is available out of the box, and ISO 27001, GDPR and HIPAA controls are part of the architecture.

Delivery

GitHub Actions with OIDC

Plan and apply in 3 to 8 minutes, federated to AWS through OIDC. No long-lived AWS keys in CI after bootstrap.

Reference architecture

The NTC building blocks

Every NTC landing zone is assembled from versioned modules. You use the ones you need and replace the ones you don't.

The Nuvibit AWS Reference Architecture (NARA): the account and module layout every NTC landing zone is built from. Click to zoom.

How it works

Four steps, no big-bang weekend

  1. Step 1

    Assess

    We inventory workloads, data stores and integrations, and classify what has to stay in the EU and what can move freely. You get a concrete timeline before any migration work starts.

  2. Step 2

    Build the landing zone

    We deploy NTC against your target architecture: organization and accounts, identity, log archive, security tooling and connectivity. Residency guardrails are in place before the first workload arrives.

  3. Step 3

    Migrate in small batches

    Workloads move in priority order, in reversible batches, and each one is validated in production before the next. That includes workloads from an existing AWS landing zone such as Control Tower or LZA.

  4. Step 4

    Operate and hand over

    You get the runbooks, the infrastructure code and pairing time with your team, and we stay available through the first weeks of steady state.

Why EU data residency comes first

Most AWS migrations treat data residency as a checkbox at the end. We start with it, because retrofitting sovereignty after a migration costs far more than designing for it.

  • GDPR by design. Data stays in EU regions unless a workload needs otherwise. Service control policies and OPA enforce that on every change.
  • EU regions by default. Frankfurt as the primary region, with Ireland, Paris, Stockholm, Milan or Spain added for latency or resilience.
  • Auditable controls. Your auditor reads the same code your team deploys, and OPA checks it before it ships.

When you need the AWS European Sovereign Cloud

Some workloads need more than an EU region: a partition that runs separately from the rest of AWS, inside the EU. The AWS European Sovereign Cloud in Brandenburg (region eusc-de-east-1) provides that. It is a new partition, so nothing moves into it in place: accounts start fresh, and Nuvibit's NTC ESC Blueprint deploys the same building blocks there. We plan which workloads belong in it and which stay in the commercial EU regions.

Track record

A real NTC deployment

Figures from a hands-on NTC landing-zone delivery through Nuvibit's partner programme.

Full NTC landing zone delivered
1-2 weeks
Terraform plan/apply feedback cycle
3-8 min
NTC deployment phases shipped end to end
6+
GitHub to AWS federation - no long-lived AWS credentials in CI after bootstrap
OIDC
Nuvibit

In partnership with Nuvibit

Delivered with Nuvibit AG, the team behind the Nuvibit Terraform Collection (NTC) - a real delivery partnership.

Frequently asked questions

Want Kubernetes app delivery on this foundation too?

Everything as a platform

A GitOps-managed platform from day one - AWS landing zone plus Kubernetes app delivery.

Ready to ship faster on AWS?

Tell us what you are building. We will map the fastest safe path to production and the platform to keep it there.

Contact usBook a callExplore solutions