Managed cloud security on AWS, Azure and Google Cloud

Managed cloud security: what it means

Managed cloud security is the service through which a partner continuously keeps control of the security of what a company runs on AWS, Azure and Google Cloud: inventory, identities and permissions, configurations, vulnerabilities, exposed data. It does not replace the provider, which runs the infrastructure: it works on the part that remains the customer's, ranks it by real risk and follows the fixes until the risk is closed.

The provider itself sets out the division of responsibilities. In Google Cloud's architecture documentation (Shared responsibilities and shared fate on Google Cloud), the provider is always responsible for the underlying network and infrastructure, while the customer is always responsible for its own access policies and its own data; in an IaaS service most security responsibilities sit with the customer. Google pairs this model with what it calls shared fate, meaning the relationship between provider and customer as an ongoing partnership to improve security.

In practice, anyone looking for a cloud security service wants answers to three questions: what do I really have in my accounts, which of these things could an attacker use today, and who takes care of it tomorrow morning. The third is the one that decides whether the work holds up over time.

This page is about the security of clouds that already exist, on one or more providers. To design, migrate or run infrastructure on Google Cloud, the service is managed cloud and infrastructure.

Where risk arises in a company's cloud

The provider is accountable for the infrastructure, and incidents almost always start in the customer's part. Google Cloud's architecture documentation says it plainly: many cloud security breaches are the direct result of a misconfiguration.

The most recent figures come from Google Cloud's Cloud Threat Horizons Report H1 2026, which analyses a subset of the incidents observed in Google Cloud environments in the second half of 2025:

• exploitation of vulnerable third-party software became the top initial access vector for the first time, with 44.5% of cases (up from 2.9% in the first half);
• access through weak or missing credentials fell from 47.1% to 27.2%;
• access through misconfigurations fell from 29.4% to 21%.

According to Google, the shift may reflect its secure-by-default strategy and stronger credential safeguards, which closed off the easiest routes. The attacks targeted unpatched applications and overly permissive user-defined firewall rules, without involving Google Cloud's infrastructure. The same report notes that in the second half of 2025 the time between the disclosure of a vulnerability and its exploitation shrank from weeks to days, and that in Mandiant's engagements on cloud and SaaS environments an identity compromise was behind 83% of compromises, with a shift from traditional phishing to vishing and theft of SaaS application tokens.

Taken together, these figures tell you where to look:

• Identities and permissions: users, roles and service accounts with more access than they need, keys that never expire, missing multi-factor authentication. This is the field of CIEM, cloud permissions management.
• Internet exposure: resources reachable from outside for no reason, open network rules, public storage.
• Workload vulnerabilities: outdated packages and images on virtual machines and containers. With exploitation windows of a few days, they are ranked by exposure, not by discovery date.
• Sensitive data: where personal and financial data sits, and who or what can reach it. This is the job of DSPM.
• Secrets: keys, tokens and passwords left in code, images or disks.

The real risk lies in the combinations: a machine exposed to the internet, with a known vulnerability and an identity that reaches a customer database, is an attack path, and it goes to the top of the queue.

What NIS2, DORA and ISO 27001 ask of the cloud

None of the three has a separate chapter for the cloud, and none of them prohibits it. All three, however, treat the cloud as part of the company's systems and the provider as a supplier to be governed.

NIS2

For essential and important entities, Article 21 of Directive (EU) 2022/2555 requires technical, operational and organisational measures for the security of the network and information systems they use in their operations: so those on AWS, Azure or Google Cloud too. Several of the minimum elements in Article 21(2) become concrete controls in the cloud: business continuity and backup management (point c), supply chain security, including relationships with service providers (d), vulnerability handling (e), cryptography (h), access control and asset management (i), multi-factor authentication (j). The provider's compliance does not transfer to the customer: accounts, configurations, identities and logs remain yours. The full picture is on our NIS2 page.

DORA

Regulation (EU) 2022/2554 treats AWS, Azure and Google Cloud as ICT third-party service providers. Article 28 establishes that financial entities using third-party ICT services remain fully responsible at all times for compliance with the obligations of the regulation. Pre-contract assessment, the register of information, concentration risk and exit plans all apply to cloud arrangements. See our DORA page.

ISO/IEC 27001

In ISO/IEC 27001:2022 the cloud has a dedicated Annex A control, 5.23 (information security for use of cloud services), alongside 8.8 on the management of technical vulnerabilities. The cloud-specific guidelines are ISO/IEC 27017 and ISO/IEC 27018. In the audit, evidence is what counts: inventories, configurations, vulnerabilities managed, access reviewed. With Vanta, that evidence is produced continuously rather than gathered before the audit.

One point applies to all three: a cloud security assessment produces useful evidence, but it does not attest compliance. It is one piece of the work, not the certificate.

Native tools, CSPM and CNAPP: what you really need

Every provider offers its own posture tool: Security Command Center on Google Cloud, Security Hub on AWS, Defender for Cloud on Azure. They are the first layer, they should be switched on regardless, and they are designed first and foremost for their own environment. The limits show when accounts multiply, when there are two or three providers and when the team reading the findings is small.

Above the native tools there are two families of platforms:

• CSPM compares configurations with rules and standards and flags deviations;
• CNAPP brings configurations, workloads, permissions, data, Kubernetes and code into a single data model, and derives the exploitable attack paths.

A CNAPP delivers most where there are real workloads on IaaS and PaaS, several accounts or several clouds, Kubernetes clusters and frequent releases. If you develop software in-house, how far upstream the platform works also matters, on infrastructure as code templates and pipelines. If instead your cloud is almost entirely SaaS, the priority is different: identities, email and tenant configuration.

When comparing platforms, the criteria that weigh are coverage of the services you use, the permissions required, where disk scanning takes place, the quality of the prioritisation, runtime coverage and integration with the SOC.

Why we work with Wiz, and what changed with Google

AmagisTech is a Wiz partner and a Google Cloud partner. Wiz is the platform we use for the cloud snapshot and to manage posture over time.

In the post announcing the close of the acquisition (Google Cloud blog, 11 March 2026), Thomas Kurian, CEO of Google Cloud, describes Wiz's work like this: it builds a real-time map of the application architecture, permissions, data flows and runtime behaviour; on that map it identifies exposure and exploitable attack paths, ranks risk by business impact and makes it possible to fix issues at the source, often before the application reaches production.

From the post and from Alphabet's filings come the facts that matter to anyone assessing Wiz today:

• Acquisition closed on 11 March 2026. The deal announced on 18 March 2025 was worth $32 billion, subject to closing adjustments; at closing Alphabet recorded $29.5 billion, after price adjustments (Form 10-Q for the quarter ended 30 June 2026, note 8). Wiz's results are reported in the Google Cloud segment.
• Brand and multicloud confirmed. Google is keeping the Wiz brand and writes that Wiz products will continue to work and be available across the major clouds, including Amazon Web Services, Microsoft Azure and Oracle Cloud, including through partners.
• Integration with Google security. Google announces a platform combining Wiz with Google Security Operations for cloud-native applications in development, build and runtime, together with Google's threat intelligence and Mandiant Consulting's frontline experience.
• Room for service providers. Google writes that it will enable system integrators, resellers and managed security service providers to offer broader services to customers, and that the combined platform will also help smaller companies, which often lack in-house skills and resources.

If you work on AWS or Azure, Wiz remains multicloud. If you already have Google SecOps, or are considering it, there is an extra advantage: Wiz issues and detections reach the SIEM with their context, and the SOC works them alongside endpoint, identity and email signals.

It pays to be precise about the connection, because it is the first question from every DevOps team. Wiz connects to the accounts via API, agentless, with a dedicated role that stays under your control and can be revoked at any time. Inventory, configurations and permissions are read via API; disk analysis, to look for vulnerabilities and exposed keys, works on temporary snapshots, not on production machines. So no agents and no impact on running systems, but not everything is read-only: the exact permissions for each cloud are reviewed together in the documentation before connecting the accounts.

How we work, phase by phase

The path starts with a snapshot and becomes ongoing management only if needed.

1. A 20-minute call

With an AmagisTech cloud advisor: which clouds you work on, how many accounts you have, who runs them, what customers, auditors or investors are asking. If you don't need the snapshot, we tell you. After your request we get back to you within 24 hours.

2. Connection and cloud snapshot

Scope (accounts, subscriptions, projects) and permissions are agreed. Whoever administers the cloud creates the dedicated role, Wiz connects via API and builds the inventory. The first prioritised list of risks arrives within the first week. The full Proof of Value takes 30 days, with a Wiz engineer working alongside our advisor.

At the end you receive the exploitable combinations with the reason for each priority, an order of action that separates quick fixes from those that need an architecture change, and evidence you can reuse for security questionnaires, due diligence and audits.

3. Ongoing management

The cloud changes every day, and a snapshot ages quickly. If you decide to continue, your posture stays under watch with Wiz: new priorities reach the right owners, fixes are verified at the next scan, audit evidence stays up to date. When you need to detect and respond to attacks in progress, cloud signals flow into AmagisTech's 24/7 SOC, built on Google SecOps and Mandiant: that is our managed SOC and MDR service.

What we need from you

• The list of accounts, subscriptions and projects across all providers, including development and test. Whatever you don't connect stays out of the snapshot.
• A person who creates the connection role, usually the cloud or DevOps lead, and who reads the required permissions first.
• A stated goal: answering an enterprise customer, preparing for an audit, understanding the overall picture. Scope and priorities depend on it.
• Who will fix things: cloud administrators, developers, suppliers. A priority list that nobody has a mandate to work on stays a list.
• A point of contact for decisions, who can say whether an exposed resource is meant to stay that way or is a leftover to switch off.

The mistakes we see most often

1. Connecting production only. Test environments and accounts created by a supplier are often the forgotten ones, and an attack path does not respect the boundaries between environments.
2. Treating the cloud as a network perimeter. If identity is behind 83% of compromises in Mandiant's cloud and SaaS cases, a closed firewall rule is not enough when a service account reaches everywhere.
3. Ranking by severity instead of exposure. A critical vulnerability on an isolated machine can wait; a medium one on an exposed machine with access to data cannot.
4. Stopping at the snapshot. Without continuous control, the problems come back with the next release.
5. Keeping posture outside the SOC. A cloud attack rarely stays in the cloud: it passes through an identity, an endpoint, email. If the signals don't reach whoever watches the rest, nobody sees the whole chain.
6. Confusing evidence with compliance. A posture report helps in the audit, but it does not replace the policies, processes, supplier management and responsibilities that NIS2, DORA and ISO 27001 ask for.
7. Assuming the provider takes care of everything. Its compliance covers its infrastructure, not your configurations. For companies selling software to large customers, that is where the questions start.

How to choose a cloud security partner, and what the cost depends on

Before the name of the platform, what counts is who will make it work on your environment. These are the questions we recommend asking any partner, us included:

• Which environment does it work on? Questionnaires and interviews help with governance, but risk becomes visible by connecting to the real accounts.
• Which permissions does it ask for, and how are they revoked? The list for each cloud should be read before starting.
• Does it cover all your providers? AWS, Azure and Google Cloud in the same view, not three separate reports.
• What happens after the list? Who follows the fixes and who checks that the risk is closed.
• Which SOC does it talk to? Without that link, posture remains a separate exercise.
• Does it speak the auditors' language? The evidence also serves NIS2, DORA and ISO 27001.
• Does it tell you when you don't need it? With a single small, stable account, run by people who know it well, the provider's native controls are often enough.

What the cost depends on

There is no one-size-fits-all price list: the cost depends on your environment, which is why it is estimated after the snapshot, on your real scope. The factors that move it are:

• the size of the scope, meaning how many workloads (virtual machines, containers, functions) run in the connected accounts;
• how many clouds and accounts are in the view;
• the modules needed: posture, code and pipelines, runtime detection;
• the service level: a one-off snapshot, managed posture over time, or monitoring with the 24/7 SOC;
• the evidence work for NIS2, DORA, ISO 27001 or SOC 2.

To compare two quotes, ask each provider which metric the price is based on and what is included.

What changes in 2026

• Wiz has been part of Google Cloud since 11 March 2026, with brand and multicloud confirmed and a combined platform with Google Security Operations. If you have or choose a SOC on Google SecOps, cloud posture and detection work on the same context.
• Exploitation windows are shrinking. In the second half of 2025 Google saw the time between disclosure and exploitation of a vulnerability shrink from weeks to days: one snapshot a year can't keep pace.
• Financial supervisors ask about the cloud too. Under DORA, financial entities keep a register of information on all their contractual arrangements with ICT third-party providers, cloud included, and have exit strategies for the services that support critical or important functions (Article 28).
• The questions come through the supply chain. Entities under NIS2 or DORA have to govern their suppliers, so cloud security questionnaires also reach companies that are not directly in scope.

The starting point stays the same: knowing what is exposed in your accounts today, with which permissions and close to which data, and deciding in what order to act.