Cloud Landing Zone in 2026: accounts, networks, IAM, guardrails, and policies for a secure start

A Cloud Landing Zone is a prebuilt foundation for launching projects securely in the cloud. It is not just a set of servers, networks, and accounts, but a baseline environment in which access controls, environment isolation, logging, budget limits, security policies, and team rules have already been thought through.

In 2026, a landing zone is especially important for SMBs and mid-sized businesses because getting started with the cloud has become easier, while controlling it has become harder. A single shared account, manually configured networks, “everyone can access everything” permissions, and no centralized logs can quickly turn a convenient cloud infrastructure into chaos.

A minimal Cloud Landing Zone should answer several questions:

●        Where prod, stage, and dev environments are hosted;

●        Which accounts or projects the team needs;

●        Who has access to which resources;

●        Which actions are prohibited by policies;

●        Where logs and audit events are collected;

●        How budgets, limits, and tags are controlled;

●        Which network zones are externally accessible and which are closed;

●        What cannot be created manually without review and approval.

For a small company, a landing zone does not have to be complex. At the start, it is enough to separate environments, configure basic access roles, enable centralized logging, set budget limits, and prohibit the riskiest actions. For example, creating public storage, granting excessive administrator privileges, or launching resources without tags.

Next, we will look at the components of a Cloud Landing Zone, what it can look like for SMBs and mid-sized businesses, which guardrails are worth enabling from the start, and which mistakes most often turn the cloud into unmanaged infrastructure.

Why it is better to prepare the cloud before launching the first projects

Cloud adoption often starts too casually: an account is registered, a virtual machine is created, a database is connected, the team is given access — and everything seems to work. For a test project, this approach may look acceptable. Problems begin later, when production goes live in the cloud and multiple teams and projects, external users, personal data, integrations, contractors, and monthly bills enter the picture.

A Cloud Landing Zone is needed before projects are launched because it defines the ground rules in advance. Not after the first outage, not after storage has accidentally been exposed to the outside world, and not after a bill arrives that is twice as high as expected. It helps establish from the start where different environments will reside, who can manage resources, which actions are prohibited, where to find logs, and how to keep spending under control.

The easiest way to think of a landing zone is as a prepared construction site. You can start building a house on an empty plot right away and think about the road, electricity, fencing, sewerage, and security later. But the further construction progresses, the more expensive it becomes to fix mistakes. The same is true in the cloud: if accounts, networks, roles, and services are created chaotically at first, they will later have to be untangled while systems are already running.

This is especially important for SMBs and mid-sized businesses. A small team often does not have a large dedicated security department, a FinOps team, or multiple cloud architects. A landing zone should therefore not make life more complicated; on the contrary, it should reduce the number of manual decisions.

The difference between launching the cloud without a landing zone and with a prepared baseline setup looks like this:

The main purpose of a landing zone is to ensure that the cloud grows in a controlled way. Instead of a random collection of resources, what appears first is a clear framework: accounts, networks, access controls, policies, logs, and financial constraints. Applications can then be migrated to this framework, new services can be launched, and teams can be onboarded.

What Is a Cloud Landing Zone in Simple Terms

We can now move on to definitions. In short, a Cloud Landing Zone is a prepared cloud environment where the first projects can be safely “landed.” That is where the name comes from: a landing zone.

It is not a specific service or a button in a provider’s console. Rather, it is a set of decisions made in advance: how environments are separated, who manages access, where network boundaries are drawn, which actions are prohibited, where logs are sent, and how costs are controlled.

Without a landing zone, the team has to answer these questions from scratch every time. One developer creates a test network in whatever way is convenient for them. Another grants a contractor direct access. A third launches a database without tags because “we’ll label it later.” After a few months, it becomes difficult to understand which resources belong to whom, why the bill has increased, and where to look for traces of a specific action.

A landing zone is needed so that basic rules do not depend on ad hoc decisions made by individual people. It establishes a common order before dozens of servers, databases, storage services, and integrations appear in the cloud.

The easiest way to break down a Cloud Landing Zone is into several layers:

In other words, a landing zone is not “yet another complicated cloud thing.” It is a way to answer in advance the questions that will inevitably come up later: where projects will reside, who will get access, how to separate environments, where to store logs, and how to avoid losing control of costs.

That is why the next step should not be choosing virtual machines or databases, but making foundational architectural decisions. Before creating the first servers, the company needs to understand how it will separate accounts, environments, and shared services.

What needs to be decided before creating the first servers

Before launching the first resources in the cloud, it is tempting to jump straight into implementation: create a virtual machine, a database, storage, and a load balancer, and start migrating the application. But a landing zone requires a different sequence. The company first decides how the cloud environment itself will be structured, and only then deploys services within it.

Otherwise, it is like repairing an engine while the vehicle is already moving. The application is already running, users already exist, the team already depends on the infrastructure, and the basic questions are still unresolved: which environment is production, which is test, who owns the network, who can modify IAM roles, and why resources from different projects are kept in the same place.

Before creating the first servers, three things need to be defined: how to divide accounts and projects, where to draw the boundaries between prod, stage, and dev, and which shared services should be placed in a separate layer. These decisions form the foundation of the landing zone and help avoid mixing production systems, tests, experiments, and administrative tools in the same place.

How to Separate Accounts, Projects, and Environments

In a landing zone, an account or project (depending on the provider’s terminology, and not to be confused with user accounts) is best treated not as a formality in the provider’s console, but as a boundary of responsibility. Production can reside in one account, a test environment in another, shared services in a third, and a sandbox for experiments in a fourth.

A small company does not always need a complex multi-level structure. However, using a single shared account for everything is a poor starting point. Real data, test resources, temporary experiments, contractor access, and costs for different business areas quickly become mixed together.

The basic logic can be as follows:

● Prod — production services, real data, critical databases and storage systems;

● Stage — a pre-release environment for validating changes before production;

● Dev — development environment, test resources, and temporary services;

● Shared services — or sometimes infrastructure/application services — shared tools: logs, CI/CD, VPN, DNS, monitoring;

● Sandbox — experiments, training, and testing of new cloud services.

This separation helps with more than security. It also simplifies cost management, auditing, and operations. If the bill increases, it is easier to understand exactly where the increase occurred. If contractor access needs to be restricted, the contractor does not have to be granted access to a shared account containing the entire business.

Accounts and projects alone are not enough, however. It is also important to understand which workloads within them belong to the production system, which are used for release validation, and which are for development. The next step is therefore to separate prod, stage, and dev not only by name, but also by actual rules.

Where to draw the boundaries between prod, stage, and dev

Prod, stage, and dev should not differ only in resource names or tags. They need real boundaries: separate accounts or projects, different access permissions, different network rules, and different data requirements.

Prod is the zone where mistakes are the most costly. It requires strict permissions, centralized logging, backups, change control, and as few people with administrative access as possible.

Stage is used to validate changes before release. It may resemble prod in its architecture, but it should not store real data unless necessary. Dev remains a more flexible environment where the team can test hypotheses faster, but even there, limits, tags, and basic restrictions are required.

Once the environments are separated, another question remains: where to put the tools that all projects need. Logs, VPN, DNS, monitoring, and CI/CD should not be duplicated in every account, so they are usually placed in a separate shared services layer.

Which common services belong in shared services

Shared services are a common layer of the landing zone. This layer contains tools that are needed not by a single application, but by the entire cloud environment. It helps avoid rebuilding the same components from scratch for every project.

This usually includes infrastructure services responsible for management, security, access, and observability. However, the shared services layer should not become a second catch-all shared account. It should host shared functions specifically, not random databases, test servers, or forgotten temporary resources.

A minimal set of shared services for an SMB might look like this:

After accounts, environments, and shared services have been separated, the landing zone has a structure. But on its own, that structure does not yet protect the cloud. The next step is to configure the elements that will hold it in place: networking, access, and policies.

Baseline landing zone framework: networking, access, and policies

Network and segmentation: so services do not all live in the same room

The network in a landing zone is not just for connectivity between services. It defines boundaries: what is accessible from the internet, what is visible only inside the cloud, which services can access databases, and which services should not even know those databases exist.

If the network is built manually as the project grows, it quickly turns into a collection of temporary fixes. Access is opened for a test today, forgotten tomorrow, and a month later no one remembers why that rule was created in the first place. That is why the network model in a landing zone is best designed in advance.

For SMBs and mid-sized businesses, a simple model is usually enough:

●        Public zone — load balancers, API gateways, and services that genuinely require inbound access from the internet;

●        Private zone — applications, internal services, queues, and backend components;

●        Restricted data zone — databases, storage systems, caches, and other sensitive services;

●        Administrative access — through a VPN, bastion host, or another controlled entry point, not directly over open SSH or RDP.

The core idea of segmentation is simple: the more critical a resource is, the fewer services and people should have direct access to it. A database should not live in the same “room” as a public web server. Administrative interfaces should not be exposed to the internet. A test environment should not have an unrestricted path to production data.

It is also a good idea to configure Security Groups/ACLs using a function-and-role-based model: each resource with a specific role, such as a load balancer, application server, database, and so on, is assigned a defined set of rules. This approach does not replace separation into zones or segments, but complements it.

Similarly, the addressing plan should be designed in advance so that segmentation is clear and easy to understand from an addressing perspective: for example, the cloud network is 10.0.0.0/8, the project/account network is 10.x.0.0/16, Dev is always 10.x.1.0/24, and prod is 10.x.250.0/24.

Once network boundaries are in place, the next question arises: even if a resource is in the correct zone, who is allowed to create, modify, and delete it.

IAM Roles and the Principle of Least Privilege

IAM is a cloud access management system. It allows a company to define who can create servers, change network rules, read logs, manage databases, issue keys, and grant permissions to other users.

The most common mistake early on is giving everyone broad permissions because it is faster. The team is small, everyone knows each other, and the project needs to launch urgently. But temporary admin access often becomes permanent. Later, contractors, new employees, multiple environments, and real data appear in the cloud, while permissions remain as if it were still a test account for three people.

In a landing zone, it is better to design access around roles rather than specific individuals:

This approach helps avoid granting permissions “just in case.” A developer does not always need access to production networks. The finance team does not need permission to delete servers. A contractor does not need full access to the account if they work with only one service in stage.

A good IAM model should not get in the way of work. Its purpose is to make access predictable: a person receives exactly the permissions they need for their task, in the right environment, and for a clearly defined period.

To grant and revoke access for new and departing employees in a timely manner, it is a good idea to integrate IAM with a central user directory, such as Microsoft Active Directory or Entra.

But even well-designed roles do not eliminate all risks. Someone may make a mistake, create a resource without tags, expose storage publicly, or launch a service in the wrong region. Guardrails are needed for these cases.

Guardrails: constraints that keep you from breaking the cloud

Guardrails are protective constraints within a cloud landing zone. They do not replace IAM, networking, or monitoring; they complement them. If IAM answers the question “who can do what,” guardrails answer the question “what is not allowed at all, or what is allowed only under specific conditions.”

A good guardrail works like a crash barrier on a road. It does not drive the car for the driver, but it prevents the car from leaving the road in a dangerous area. In the cloud, these “barriers” can include bans on publicly accessible storage, mandatory encryption, regional restrictions, bans on resources without tags, or blocking overly expensive instance types.

At the outset, there is no need to try to cover every possible scenario. For a small company, it is more important to enable a few basic constraints:

●        A ban on public access to storage without separate approval;

●        Mandatory tags for the project, owner, environment, and cost center;

●        Regional restrictions if data must not leave the selected jurisdiction;

●        A ban on disabling logging and auditing;

●        An encryption requirement for databases, disks, and storage;

●        Budget limits or alerts for dev, sandbox, and experimental projects.

Guardrails are especially useful where an error may go unnoticed. An open port, a resource without an owner, an unencrypted database, or a forgotten test server does not always break the system immediately. But these are exactly the kinds of small issues that later lead to data leaks, unnecessary costs, and complex investigations.

Observability and cost control as part of the foundation

Network, IAM, and guardrails define the rules within a landing zone. But rules are of little help if the company cannot see what is happening in the cloud. You can prohibit certain risky actions, separate environments, and configure roles, yet still miss suspicious activity, a sudden spike in spending, or a resource that no one has used for a long time.

That is why observability and cost control should be treated not as optional add-ons, but as part of the core foundation. Logs, auditing, budgets, and tags are best put in place from the start, while the cloud environment is still small. Later, when there are more projects, putting all of this together retroactively will be much harder.

Centralized Logging and Auditing

Logs in a landing zone are not just for developers. They provide answers to simple but critical questions: who created a resource, who changed a network rule, who granted permissions, where a request came from, why a service became unavailable, and what happened before an incident.

If logs are stored separately in each account or project, an investigation quickly turns into archaeology. The team has to open different consoles, compare event timestamps, track down access rights, remember who changed what, and try to piece the picture together manually.

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure

Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans

Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus

Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster

In a landing zone, it is best to set up a unified logging layer from the start. Events from prod, stage, dev, and shared services should be sent to a centralized storage location or monitoring system. Access to these logs must be restricted, and the retention period should be defined in advance.

At a minimum, you should collect:

●        Resource management events;

●        Changes to IAM roles and policies;

●        Network events and access attempts;

●        Security events;

●        Logs from critical applications;

●        Actions performed by administrators and service accounts.

It is especially important to protect the logs themselves from deletion and modification. If an attacker or an administrator who made a mistake can easily erase the traces, auditing loses its value. That is why logs are often stored in a separate storage location with restricted permissions and a defined retention policy.

Once events are collected centrally, the next challenge is not just to see technical changes but also to understand how much each part of the cloud costs.

Budgets, limits, and financial guardrails

One of the traps of the cloud is the perception that resources are almost unlimited. A server can be created in a minute, a database in a few clicks, and a test cluster “just for the evening.” But the bill is based not on intentions, but on actual runtime hours, disks, traffic, backups, load balancers, and additional services.

For SMBs and mid-sized businesses, this is especially important. A single forgotten test resource may not be a disaster for a large corporation, but it can be a painful blow for a small team. That is why cost control should be part of the landing zone, not an accounting task at the end of the month.

Basic financial guardrails can be described as follows:

Financial constraints should not block the team’s normal work. Their purpose is to surface deviations in time. If the dev environment suddenly starts costing almost as much as prod, it is not always an error, but it is definitely a reason to investigate.

Tagging Policy for Resources and Costs

Tags may seem like a minor detail when there are only a few resources. But once the cloud has dozens of servers, disks, databases, storage services, and network components, it becomes difficult to understand who owns what without tags.

A tagging policy answers several practical questions: which project the resource belongs to, who owns it, which environment it is associated with, which cost center it maps to, and whether it can be deleted. Without this information, the infrastructure gradually turns into a warehouse of unlabeled boxes.

You do not need to define dozens of tags at the start. It is better to choose a small mandatory set and make it clear to the team.

For example:

●     Project — name of the project or product;

●     Environment — prod, stage, dev or sandbox;

●     Owner — the team or responsible owner;

●     Cost_center — expense category;

●     Managed_by — manually, Terraform, CI/CD, or another management method.

It is important not just to document tags, but to embed them in the landing zone rules. Resources without mandatory tags can be prohibited, flagged as policy violations, or regularly included in a report for review.

Example Cloud Landing Zone Architecture for SMBs and Mid-Sized Businesses

After covering the basic principles, it is useful to bring everything together into a practical design. Not as an ideal architecture for an enterprise with dozens of teams, but as a realistic option for an SMB or mid-sized business: several projects, a small team, a limited budget, but already with production, test environments, external users, and security requirements.

In this model, the landing zone must be simple enough for the team to maintain. At the same time, it must define boundaries from the outset: where production services belong, where experiments belong, who manages access, where logs are sent, and which actions cannot be performed without oversight.

How to structure accounts, environments, and shared services

A baseline architecture can start with several separate accounts or projects. You do not necessarily need many, but each should have a clear role. The main mistake is trying to fit everything into a single shared account because you are “still small.” That “still” is exactly what later leads to mixed access permissions, unclear costs, and fear of changing anything.

For SMBs, you can use a simple structure:

This separation does not require complex bureaucracy, but it immediately creates clear boundaries. Prod is not mixed with testing. Shared services do not turn into a dumping ground for random servers. Sandbox can be limited by budget and access rights so that experiments do not affect production systems.

Within this structure, it is important to assign owners. Every project should have someone responsible for it: a team, a product owner, or a technical lead. Otherwise, even a well-designed structure quickly turns into a collection of resources that belong to no one.

How to tie together networking, IAM, logs, budgets, and guardrails

After separating accounts and environments, you need to tie them together with a common set of rules. Otherwise, the design will look good only on paper, while each project will still configure networking, access, logs, and budgets in its own way.

Network defines the technical boundaries. Public access remains only for external entry points: the load balancer, API gateway, or web service. Databases, internal services, and administrative interfaces must remain in private zones.

IAM is responsible for access management. It is better to assign permissions by role rather than manually to each individual. A developer works with dev and stage, an operator with production operations, security with auditing and policies, and the finance role with budgets and reports.

Logs and budgets make the landing zone visible. Without logs, it is difficult to understand who changed a rule, granted access, or created a resource. Without budgets, the team only finds out about the problem after the invoice arrives. Therefore, events from all environments should be sent to a central framework from the outset, and limits or alerts should be enabled for dev and sandbox.

Guardrails cover the most dangerous scenarios: public storage, resources without required tags, disabled audit logging, or deployment in an inappropriate region. They are not a replacement for engineers, but a safety net against mistakes that can be far too costly in the cloud.

As a result, the landing zone works as a unified system: networking restricts paths to resources, IAM manages access, logs show what is happening, budgets keep spending under control, and guardrails prevent violations of the baseline rules.

Next, it is worth discussing an equally important area: common mistakes.

Common mistakes when starting without a landing zone

Structure: a single account, mixed environments, and manually configured networks

The most common mistake is running everything in a single account or project. Prod, stage, dev, test databases, temporary servers, contractor access, and forgotten experiments all end up in the same place. When there are only a few resources, this may seem convenient. But as the cloud environment grows, it becomes increasingly difficult to tell which resources belong to the production system, which are for testing, and which are old resources that no one uses anymore.

The second issue is mixing environments. If dev can access production data, and stage uses the same network rules as the production environment, a testing error can affect real users. Environments must differ not only in name, but also in permissions, networks, data requirements, and level of control.

Manual network configuration makes this chaos worse. Today the team opens a port for testing, tomorrow it adds a temporary rule, and later it allows access from a new address. After a few months, the network rules start to look like an old cabinet: everything seems necessary, but no one remembers exactly why.

These mistakes typically look like this:

Fixing this after launch is harder than setting it up correctly in advance. This is especially true if the application is already running, the team is used to the old access model, and some resources cannot simply be moved without downtime.

Governance issues: flat permissions and no logs, tags, or budgets

The second group of mistakes is not about where resources are located, but about how they are managed. At the start, it often seems easier to give everyone admin access and avoid spending time on roles. The team is small, there is trust, and tasks are urgent. But the cloud environment grows quickly, people change, contractors and new services appear, while permissions remain too broad.

A flat access model is dangerous because it provides almost no protection against accidental actions. One person can change the network, delete a resource, expose storage, or grant access to others. Even if no one intended to cause harm, the cost of a mistake becomes too high.

Without centralized logs, the team loses its memory. It becomes impossible to quickly understand who changed a policy, when public access appeared, why costs increased, or where the problem began. During an incident, instead of investigating using logs, the team has to piece together the timeline from chats and recollections.

The absence of tags and budgets undermines manageability. Resources exist and invoices arrive, but it is unclear how much each project uses and who is responsible for it. This is especially problematic in dev and sandbox environments, where a forgotten test server or disk can quietly remain in place for months.

A minimum set of management rules should be introduced from the start:

●        Access is granted based on roles, not as “everything for everyone”;

●        Management and security logs are collected centrally;

●        Resources have mandatory tags for project, environment, and owner;

●        Budget alerts are enabled for dev, sandbox, and experiments;

●        Exceptions to permissions and policies are recorded, not kept in message threads.

These rules do not make the cloud environment perfect. But they eliminate the most dangerous blind spots: unclear access, invisible changes, ownerless resources, and costs that are discovered too late.

After reviewing these mistakes, it becomes clearer why a landing zone should not be implemented as a massive corporate project. For a small team, it is more important to start with a minimal managed foundation and gradually strengthen it as the cloud environment grows.

How to implement a landing zone without overloading a small team

A Cloud Landing Zone does not have to be implemented as a large six-month project. For a small team, that approach can even be harmful: the architecture may become too heavy before any real workloads appear in the cloud. It is better to move in stages and address the most visible risks first.

A good starting point is a minimal baseline. First, the team separates prod, stage, dev, and shared services. Then it configures basic access roles, enables centralized logging, adds required tags, and sets up budget alerts. After that, guardrails can be introduced: blocking public storage, restricting regions, requiring encryption, and controlling unowned resources.

Implementation can be roughly divided into three stages:

●        Establish the foundation. Separate prod, stage, dev, and shared services, assign project owners, and move critical resources out of the shared account.

●        Add governance. Configure IAM roles, centralized logs, mandatory tags, and budget alerts.

●        Strengthen security. Enable guardrails, restrict public access, enforce regions, add encryption, and gradually migrate settings to IaC.

Automation can also be introduced gradually. For example, start by defining the baseline network and accounts in Terraform, then IAM roles, followed by policies and guardrails. The key is not to leave critical settings as manual configuration only. If a landing zone cannot be reproduced, validated, and redeployed, over time it will begin to drift from the documentation.

For SMBs and mid-sized businesses, a reasonable goal is not to build something “like a hyperscaler reference architecture,” but to create a clear foundation.

Conclusion

A Cloud Landing Zone is not a separate trendy layer on top of the cloud, but a way to agree on the basic rules in advance: where prod, stage, and dev reside, who gets access, how the network is structured, where logs are sent, what spending is acceptable, and which actions are prohibited by policies.

For SMBs and mid-sized businesses, a landing zone is especially important because a small team cannot always compensate for chaos through manual oversight. If everything depends on one engineer’s memory, temporary access, and settings configured “as best they could,” the cloud quickly becomes difficult to support.

A good landing zone does not have to be complex. Its purpose is to give the company a secure starting point: separate environments, restrict unnecessary permissions, enable logging, configure budgets, standardize tags, and add guardrails against the riskiest mistakes.

FAQ

Can you run a cloud environment without a landing zone?

Yes, especially for a short test or a prototype with no real data. But for a live project, this approach quickly creates risks: mixed environments, excessive permissions, unclear costs, and no proper auditing.

If the project is expected to grow, it is better to prepare at least a minimal landing zone before going into production.

Does a small business need a landing zone?

Yes, but it does not need to be as complex as one used by a large enterprise. For a small business, a basic structure is usually sufficient: separate environments, clear IAM roles, centralized logs, tags, budget alerts, and a few mandatory guardrails.

How does a landing zone differ from a standard cloud architecture?

A standard cloud architecture describes a specific application: servers, databases, load balancers, queues, storage, and the relationships between them.

A landing zone describes the environment in which these applications will run. It covers accounts, networks, access controls, policies, logs, budgets, tags, and shared security rules.

Can a landing zone be built gradually?

Yes, and for a small team this is often the best approach. You can start by separating prod, stage, and dev, then configure IAM and logging, and later add tags, budgets, guardrails, and automation using IaC.

The key is not to postpone foundational decisions until you already have dozens of resources and several critical services in the cloud.

What matters most at the start: IAM, networking, or logs?

It is better not to treat them separately. Networking restricts technical access to resources, IAM defines permissions for users and services, and logs show what is actually happening in the cloud.

If you need to prioritize, start by covering the basics: do not expose critical resources to the internet, do not grant permanent admin access to everyone indiscriminately, and enable activity auditing right away.

Do you need to use Terraform, or can everything be configured manually?

In the very early stages, some settings can be configured manually if the cloud environment is small and the team is only validating the approach. However, critical landing zone components should be gradually moved to IaC: accounts, networks, IAM roles, policies, guardrails, and core services.

Manual configuration is convenient for a one-off setup. But if the environment needs to be reproduced, validated, restored, or changed without chaos, infrastructure as code becomes far more reliable.

Sources

1. AWS Prescriptive Guidance

2. AWS Control Tower

3. Microsoft Azure Cloud Adoption Framework

4. Google Cloud Architecture Center

 5. CIS Controls v8.1 and Cloud Companion Guide