Nimbiora Landing Zone

Nimbiora Landing Zone v.1.0.0 - Last updated: 13/05/2026

Further reading

What is a Landing Zone?

An AWS Landing Zone is a ready‑made starting point for your cloud environment. Instead of opening a brand‑new AWS account and “figuring things out as you go”, you get a foundation where security, access, and structure are already designed and implemented for you.

You can think of it like moving into a fully equipped office instead of an empty building:

In an empty office, you must handle everything: doors and locks, internet, Wi‑Fi, meeting rooms, cleaning, and security. Every office might end up slightly different, depending on who set it up.
In a ready‑to‑use office, everything is already in place: secure access, desks, Wi‑Fi, meeting rooms and rules for how spaces are used. Every floor follows the same standards.

A Landing Zone does the same for AWS:

It defines how accounts are created and organized
It sets security and compliance rules from the beginning
It standardizes networking, monitoring, and backups
It makes everything repeatable and auditable instead of “best effort”

Without a Landing Zone, companies often:

Configure every new AWS account differently
Forget important security controls
Struggle to prove compliance to auditors or customers
Accumulate “cloud debt” – messy, inconsistent setups that are hard to fix later

With a Landing Zone, you get:

Consistency – the same rules everywhere
Security by default – protection is built in, not added later
Scalability – easy to add new accounts, teams, and regions
Faster delivery – teams can focus on business workloads, not plumbing

The Nimbiora Landing Zone in simple terms

The Nimbiora Landing Zone is a pre‑built AWS foundation created specifically for small and medium‑sized companies that want:

A safe first step into AWS
A structure that will still work when they grow
Strong security and compliance without hiring a large cloud team

Technically, it is implemented using Infrastructure as Code tools (Terraform and Terragrunt). For you, the important point is: the entire setup is described as code , so it is:

Repeatable – we can recreate your environment exactly
Auditable – you can see what is configured and how it changed over time
Easier to evolve – you can update your foundation safely as your needs grow

Sandbox now, production later

Version 1.0.0 of the Nimbiora Landing Zone focuses on a Sandbox environment:

A safe space to experiment with AWS
Ideal for testing, training, and proof‑of‑concepts
Uses the same structure and best practices that will be used in production

When you are ready, this sandbox can be upgraded and hardened into a production‑grade Landing Zone . You keep the same:

Structure
Automation
Accounts

You will simply add more accounts and features, tailoring for your future needs.

Core design principles

Multi‑account structure: separating responsibilities

Instead of putting everything into a single AWS account, the Nimbiora Landing Zone uses several dedicated accounts, each with a clear role. You can think of them like departments in a company building:

Management account – the “head office”
- Handles overall organization, billing, and high‑level policies
- Kept as empty and secure as possible for safety
Network account – the “building’s IT and cabling”
- Manages private networks, connections between systems, and VPN access
- Keeps network changes centralized and controlled
Security account – the “security control room”
- Central place for security monitoring and alerts
- Collects logs from all accounts (who did what, where, and when)
- Runs services that detect threats, misconfigurations, and sensitive data exposure
Operations account – the “operations and monitoring center”
- Shared tools for monitoring, automation, and backups
- Helps your team see what is running across all accounts in one place
Sandbox / workload accounts – where your applications and tests live
- Isolated from the core platform
- Can have more relaxed limits for experimentation
- Still benefit from the same security and logging backbone

This separation is a core AWS best practice. It reduces risk: if something goes wrong in one account, it is less likely to impact everything else.

Built as code, not by hand

All of this is built and managed using Infrastructure as Code (IaC) .

In non‑technical terms:

There is a blueprint in code describing your AWS foundation
Changes go through a review process (like reviewing a contract)
Nothing is changed manually in the console “by clicking around”, which avoids surprises

Benefits for you:

You always know what is deployed
You can see the history of changes
You can reproduce the same setup in another region or environment

Security and compliance from day one

The Nimbiora Landing Zone is aligned with major security standards, so you start from a position of strength rather than trying to “bolt on” compliance later.

Out of the box, the environment is designed to achieve a very high score (above 95%) against:

CIS AWS Foundations Benchmark
AWS Foundational Security Best Practices
NIST 800‑53 (a widely used security control framework)

In practical terms, this means:

Logging is enabled everywhere (who did what, where, and when)
Misconfigurations are continuously detected
Data is encrypted by default
Public exposure is tightly controlled
Passwords, access, and permissions follow strict rules

Ready for multiple regions and growth

The Landing Zone is set up with:

A primary region (for most workloads)
A backup region (for resilience and disaster recovery scenarios)
The global region (needed for some AWS services)

This makes it easier to grow internationally or improve resilience later, without redesigning everything from scratch.

What you get in practice

Below is a simplified explanation of the main capabilities you mention in your technical document, rewritten for a non‑technical audience.

Security and monitoring

From day one, the Landing Zone activates key AWS security services across your accounts:

Threat detection AWS services continuously watch for suspicious activities such as unusual login patterns, data access, or network behavior. Alerts are centralized in the Security account so they cannot be silenced or tampered with from a workload account.
Configuration monitoring The platform continuously checks if your AWS accounts follow the expected security rules (for example, “no public databases”, “encryption enabled”). If something drifts from the standard, it is detected and reported.
Central logs All important logs (access logs, configuration changes, DNS queries, network flow logs, and more) are stored in a dedicated, protected location. This makes forensic analysis and audits possible and helps demonstrate compliance.
Security dashboards Security services aggregate their findings and show an overall “score” and list of issues, so you can clearly see your cloud security posture.

Identity and access: how people log in

Instead of creating long‑lived user accounts directly in AWS, the Landing Zone uses AWS Identity Center :

Your staff log in through a single portal with their company identity (or a built‑in identity if you prefer to start simple)
They receive short‑lived, role‑based access to specific accounts and roles
There is no need to share passwords or access keys
Permissions are organized into roles like:
- Developer
- Security
- Operations
- Network
- Finance / Billing
- Auditors

This reduces risk and makes it easier to align access with responsibilities and audits.

Operations: making day‑to‑day work easier

The Nimbiora Landing Zone includes operational capabilities such as:

Inventory and patching AWS Systems Manager is set up so you can see which servers exist, their status, and manage their updates centrally.
Cost control
- Baseline budgets and anomaly detection to catch unexpected spikes in cost
- Scheduling tools to automatically stop non‑production servers outside office hours (for example, to avoid paying for test systems overnight)
Central monitoring Metrics and, optionally, logs and traces from your accounts can be sent to the Operations account, where dashboards and alarms can be configured.

Networking: connecting things safely

Networking is centralized in the Network account:

A central IP address plan avoids collisions when new environments or VPCs are created
Workload environments are connected in a controlled way (for example via a hub‑and‑spoke Transit Gateway model, or simpler VPC peering for smaller setups)
A managed VPN platform can give your engineers secure access from their laptops into the AWS environment

All of this is designed so that:

Workloads can talk to each other only when they should
Internet‑facing components can be strictly controlled
The architecture can grow as you add more applications and teams

Backup and recovery

Backups are managed centrally:

Backup rules are defined at the organization level and applied consistently
Important systems can have cross‑region and locked backups , meaning:
- Copies are stored in a separate, dedicated backup account
- Backups can be protected against accidental or malicious deletion (using AWS “vault lock” and retention rules)
Different classes of backups can be used (critical, standard, archive), depending on the importance of the data

This provides a strong foundation for disaster recovery and regulatory requirements.

Why choose the Nimbiora Landing Zone

Security and compliance from day zero You don’t grow into security; you start with it. The platform is aligned with recognized benchmarks and frameworks.
Structure that matches how modern cloud is done Multi‑account, multi‑region, with clear separation of concerns (security, network, operations, workloads).
Designed for SMEs and fast‑moving teams Minimal initial complexity and cost, but with a clear path to a production‑grade, enterprise‑class Landing Zone.
Fully codified, no black box Everything is Infrastructure as Code. You keep the code and control over your environment.
Built for learning and migration The Sandbox environment is perfect for training, experimentation, and early projects. When you are ready, the same patterns apply to production.

Table of Contents