The act of launching a new virtual machine or compute instance inside a cloud environment. Attackers abuse this capability to bypass controls on existing systems, attach copied data, stage tools, and apply looser security settings. It is especially risky when provisioning rights are broader than operational need.
Expanded Definition
Create cloud instance refers to the provisioning action that spins up a new cloud-hosted compute resource, typically a virtual machine or equivalent service instance, within an existing tenant or account. In security terms, the risk is not the instance itself but the authority used to create it, the defaults applied at launch, and the speed at which an attacker can use that fresh asset to operate outside established monitoring patterns. This is why the term sits at the intersection of cloud administration, identity governance, and operational security rather than simple infrastructure management.
For NHI Management Group, the important distinction is between legitimate provisioning and abuse of provisioning rights. A cloud instance may be created through a portal, API, IaC pipeline, or delegated automation identity, and each path carries different control expectations. Definitions vary across vendors on whether the term includes ephemeral containers or only VM-style resources, so usage should be read in context rather than assumed to be universal. The most common misapplication is treating instance creation as a low-risk technical task, which occurs when provisioning permissions are granted broadly and launch-time security settings are not reviewed.
Examples and Use Cases
Implementing controls around create cloud instance rigorously often introduces friction in fast-moving engineering workflows, requiring organisations to weigh deployment speed against governance, traceability, and least privilege.
- A DevOps service account creates a new test instance through an automated pipeline, and the security team verifies that the identity is limited to approved subscriptions and approved images.
- An attacker with compromised admin credentials creates a separate instance to stage tools after tampering with logging on the original system, making detection harder.
- A cloud operations team uses instance creation to isolate a forensic copy of a workload, preserving evidence while preventing contamination of production data.
- A misconfigured role allows a contractor to create compute resources with public networking, exposing sensitive workloads to unnecessary reachability.
- An incident responder provisions a clean instance to rebuild a compromised application, then uses it to validate recovery steps before rejoining the service to production.
For governance context, the NIST Cybersecurity Framework 2.0 is useful for mapping instance creation to asset management, access control, and continuous monitoring expectations.
Why It Matters for Security Teams
Create cloud instance becomes a security issue when provisioning is disconnected from identity assurance, change control, and asset visibility. A newly created instance can bypass hardened baselines if launch templates are weak, if logging is not inherited, or if cloud IAM allows broad self-service creation across accounts and regions. That creates a practical path for persistence, data staging, and segmentation bypass, especially where non-human identities or automation roles are allowed to create resources without tight approval boundaries.
Security teams should treat instance creation as a privileged action, not a routine utility function. That means reviewing who can create compute resources, which images and network settings are permitted, and whether every new asset is enrolled into monitoring at creation time. The same concerns apply when agentic automation is allowed to provision infrastructure, because the agent’s execution authority can become an indirect pathway to create unauthorized compute. Organisations typically encounter the real impact only after an incident reveals an unexpected instance used for persistence, at which point create cloud instance becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Cloud instance creation depends on limiting and governing privileged access paths. |
| NIST Zero Trust (SP 800-207) | SC-7 | Instance creation can create new trust zones and network exposure that ZTA seeks to constrain. |
Restrict instance provisioning to approved identities and review those entitlements regularly.