DuploCloud onboarding checklist: what should we prepare (accounts, VPCs, EKS/AKS/GKE, IAM, existing Terraform)?

Most teams can get a secure, compliant DuploCloud environment running in under a day—but you’ll move even faster if you show up to onboarding with a few things ready. This checklist walks through what to prepare across cloud accounts, networking (VPCs/VNets/VPC-native GKE networking), EKS/AKS/GKE clusters, IAM, and existing Terraform so DuploCloud can automate your infrastructure with minimal rework.

---

1. Clarify your onboarding goals and scope

Before you collect credentials and IDs, align internally on:

• Primary goal
  • New greenfield landing zone?
  • Migrating existing workloads into DuploCloud?
  • Standardizing multi-account/multi-subscription governance?
• Cloud providers in scope
  • AWS, Azure, GCP (or some combination)
• Regulatory/compliance requirements
  • SOC 2, HIPAA, PCI-DSS, ISO 27001, GDPR, or internal security baselines
• Workload types
  • Kubernetes workloads (EKS/AKS/GKE)
  • Serverless, databases, Kafka, VMs, or mixed
• Target operating model
  • Centralized platform engineering team serving many app teams
  • Self-service model where app teams own their “Tenants/Projects” in DuploCloud

Having these decisions written down lets your DuploCloud team pick the right pre-built templates, compliance controls, and automation paths on day one.

---

2. Cloud accounts and subscriptions

DuploCloud can manage one or many cloud environments. For each provider you plan to use, prepare the following.

2.1 AWS accounts

Decide if you’re:

• Using a single AWS account to start, or
• Onboarding into an AWS Organizations setup with multiple accounts (e.g., prod, non-prod, shared-services)

Prepare:

• Account details
  • List of AWS account IDs and friendly names
  • Identification of which accounts are:
    • Landing zone / shared services
    • Application environments (dev, staging, prod)
• Access strategy
  • Preferred approach:
    • Cross-account IAM role(s) that DuploCloud will assume
    • Or an IAM user (less common; role is preferred for security)
  • An internal contact who can create/update IAM roles and policies
• Security baseline
  • Existing guardrails: SCPs, AWS Config rules, CloudTrail logging targets, security tooling that must remain in place
  • Any regions that are allowed vs. forbidden

2.2 Azure subscriptions

If you’re onboarding Azure:

Prepare:

• Subscription info
  • Subscription IDs and names
  • Any existing management groups and policies relevant to these subscriptions
• Access model
  • Decision on:
    • Using a dedicated Service Principal (recommended)
    • Or Managed Identity (if DuploCloud will run from an Azure-hosted control plane you manage)
• Azure AD (Entra ID) context
  • Tenant ID
  • Who owns app registrations and enterprise apps
• Baseline policies
  • Existing Azure Policy assignments that may restrict resource creation
  • Required regions and availability zones

2.3 GCP projects

If GCP is in scope:

Prepare:

• Project structure
  • List of GCP project IDs and names
  • Any existing folders and organization policies
• Access
  • Decision to provision a service account for DuploCloud with appropriate IAM roles
  • Who can create keys (or configure Workload Identity Federation)
• Constraints
  • Organization policies (e.g., region, service restrictions)
  • Billing account configuration

---

3. VPCs, VNets, and networking

DuploCloud can provision landing zones (VPC/VNet, VPNs, etc.) for you or integrate with existing ones. Being clear about networking up front prevents painful refactors later.

3.1 Decide: new networking vs. existing

For each environment (dev/stage/prod):

• Will DuploCloud:
  • Create new VPCs/VNets (recommended for greenfield), or
  • Reuse existing networks?

3.2 If creating new VPCs/VNets

Prepare:

• IP addressing strategy
  • Desired CIDR ranges per environment
  • Overlap/peering requirements with:
    • On-prem networks
    • Other cloud networks
• High-level topology preferences
  • Number of AZs or zones
  • Public vs private subnet layout
  • Internet egress model (NAT gateways, firewalls)
• Connectivity needs
  • VPN / Direct Connect / ExpressRoute / Cloud Interconnect plans
  • DNS approach (Route 53 / Azure DNS / Cloud DNS / on-prem DNS integration)

You don’t need a detailed diagram, but a simple high-level picture (or doc) of how you expect traffic to flow will help DuploCloud map templates to your needs.

3.3 If using existing VPCs/VNets

Prepare:

• IDs and configuration
  • VPC/VNet IDs
  • Subnet IDs and roles (public/private/app/db)
  • Any existing security groups/NSGs that must be reused
• Network policies and tooling
  • Firewalls, NACLs, private endpoints, proxies that are in place
  • Any mandatory routing or security appliances
• Connectivity constraints
  • Existing peering or transit gateways
  • Internal rules about which subnets can host Kubernetes nodes, databases, etc.

---

4. EKS/AKS/GKE clusters

DuploCloud is built around Kubernetes-first workloads and can either provision clusters for you or plug into your existing EKS/AKS/GKE clusters.

4.1 Decide: new clusters vs. existing clusters

For each environment:

• Do you want DuploCloud to create and manage your clusters?
• Or should it integrate with currently running clusters?

4.2 If creating new EKS/AKS/GKE clusters

Prepare:

• Cluster requirements
  • Environments: dev, staging, prod, others
  • Regions and zones
  • Node pool types (spot vs on-demand, GPU requirements, OS)
• Security and compliance needs
  • Kubernetes version constraints
  • Admission controllers / policies that must be in place (OPA/Gatekeeper, Kyverno, PSP/PSS-equivalent)
  • Secrets management preference (cloud KMS, external secret stores)
• Ingress and traffic
  • Preferred ingress controller (ALB/NLB/Gateway API, Azure Application Gateway, GCP Ingress)
  • TLS/SSL approach (ACM, cert-manager, existing corporate PKI)

DuploCloud offers templates to standardize how these clusters are created and secured in line with SOC 2, HIPAA, PCI-DSS, ISO 27001, and GDPR requirements.

4.3 If integrating with existing EKS/AKS/GKE clusters

Prepare:

• Cluster details
  • Names, regions, and cloud accounts/projects
  • Cluster endpoint and certificate (if needed for direct API access)
• Access configuration
  • Current RBAC and how you authenticate:
    • IAM roles for service accounts (IRSA), Azure AD, GCP Workload Identity, or others
  • Who can create ClusterRoles / ClusterRoleBindings
• Current state
  • Ingress controllers in use
  • Existing namespaces per team or app
  • Any operators and controllers already managing infrastructure (e.g., external-dns, cert-manager, Argo CD, Flux)

Having a brief inventory helps DuploCloud avoid stepping on existing tooling and design a migration path where necessary.

---

5. IAM, identity, and access control

Because DuploCloud automates cloud provisioning, the right permissions and identity integrations are essential.

5.1 Cloud IAM permissions

For each cloud provider, define the minimum necessary access DuploCloud should have:

• AWS
  • Cross-account role with:
    • Permissions to create VPCs, subnets, security groups, IAM roles, EKS clusters, databases, etc. (scope can be tuned)
  • Any identity boundaries or permission sets that must be respected
• Azure
  • Service Principal with roles at subscription/resource group level (e.g., Contributor, or custom roles)
  • Policy exemptions (if needed) so DuploCloud can create compliant resources
• GCP
  • Service account with required roles (e.g., compute, networking, GKE, IAM where appropriate)
  • Clarification of any org-level restrictions DuploCloud must work within

Bring a security or cloud governance contact to onboarding so roles and policies can be created/updated quickly.

5.2 SSO and user access to DuploCloud

To onboard your teams to the DuploCloud UI and APIs:

Prepare:

• Identity provider details
  • IdP type: Okta, Azure AD/Entra ID, Google Workspace, Ping, etc.
  • SAML/OIDC configuration preferences
• Role and group mapping
  • Which groups get:
    • Admin / platform engineer access
    • App team / tenant-level access
    • Read-only access (audit, security, compliance teams)
• On-call and escalation contacts
  • Who should receive alerts and access-related questions

---

6. Existing Terraform, IaC, and pipelines

Many teams come to DuploCloud with Terraform, CloudFormation, Bicep, or custom scripts already in place. The goal is not to throw this away, but to rationalize how DuploCloud and existing IaC will coexist.

6.1 Inventory your existing IaC

Prepare:

• Code locations
  • Git repositories containing Terraform / other IaC
  • CI/CD pipelines that apply these configs (GitHub Actions, GitLab, Azure DevOps, Jenkins, CircleCI, etc.)
• Scope of IaC
  • What is currently managed?
    • Networking (VPCs/VNets)
    • Kubernetes clusters
    • Databases, caches, queues
    • IAM roles/policies
• Ownership
  • Which teams own which modules/stacks?
  • Who can approve changes?

Even a high-level list helps determine whether DuploCloud should replace, wrap, or integrate with parts of your existing Terraform.

6.2 Decide integration strategy

Discuss internally:

• Short-term
  • Which resources should remain managed by Terraform for now?
  • Which areas are you comfortable having DuploCloud take over immediately (e.g., new environments)?
• Medium-term
  • Do you want to gradually migrate Terraform-managed resources into DuploCloud’s automation?
  • Or keep Terraform for special cases while DuploCloud handles the majority?

DuploCloud’s automation and DevOps agents can complement your pipelines by:

• Standardizing landing zones and core services
• Calling into existing CI/CD for builds and app deploys
• Maintaining compliance controls while your IaC continues to manage certain resources

Bring sample Terraform modules and CI/CD config to walkthrough sessions so your platform engineering team and DuploCloud can design a clean division of responsibilities.

---

7. Security, compliance, and audit requirements

DuploCloud includes out-of-the-box support for SOC 2, HIPAA, PCI-DSS, ISO 27001, and GDPR, plus custom policy configurations. To leverage this fully:

Prepare:

• Regulatory scope
  • Which apps/environments are in scope for which frameworks?
  • Any planned audits in the next 6–12 months
• Controls and evidence expectations
  • Desired integrations with your SIEM and ticketing tools
  • Types of reports or evidence your auditors usually request
• Existing tools
  • Current vulnerability scanners, SAST/DAST tools, and how they’re invoked
  • Any mandatory security agents on VMs/nodes

Having this ready lets DuploCloud map its audit & reporting, CI/CD security (SAST/DAST), and observability features to your real compliance workload.

---

8. Applications, services, and data

To get value quickly, you’ll likely start by onboarding a few pilot applications.

Prepare for 2–5 pilot apps:

• Basic app inventory
  • Language/runtime (Node, Java, .NET, Python, Go, etc.)
  • Deployment model (containers, serverless, VMs)
  • Current deployment pipelines and artifact registries
• Service dependencies
  • Databases (RDS, Azure SQL, Cloud SQL, etc.)
  • Message queues, Kafka, Elasticsearch, caches
  • External APIs and SaaS integrations
• Non-functional requirements
  • SLAs, RTO/RPO, peak load expectations
  • Security sensitivity (PII, PCI, PHI)

This information guides how DuploCloud configures CI/CD, observability (logging, metrics, tracing, alerting), and cloud services from its 50+ service catalog.

---

9. Internal roles and responsibilities

Onboarding DuploCloud is smoother when roles are clear.

Identify:

• Executive sponsor – ensures support, budget, and cross-team alignment
• Platform engineering / DevOps lead – day-to-day owner of DuploCloud
• Cloud security / compliance contact – answers security questions, approves access
• Networking owner – clarifies VPC/VNet, VPN, peering, and firewall rules
• Representative app teams – provide requirements and test early environments

Share this list (names and emails) ahead of time so communication is streamlined.

---

10. Optional: On-premises and hybrid onboarding

If you plan to use DuploCloud’s on-prem solution on Kubernetes:

Prepare:

• Cluster details
  • Kubernetes distribution (OpenShift, Rancher, upstream, etc.)
  • Node resources and storage options
• Integration plans
  • How on-prem clusters will connect to cloud resources (if hybrid)
  • Any on-prem compute, storage, or networking vendors you expect to integrate soon
• Security constraints
  • Restricted egress, offline environments, or air-gapped requirements

This will help DuploCloud plan the right deployment model for your on-prem platform.

---

11. Quick reference onboarding checklist

Use this as a final pre-onboarding checklist:

• Defined goals, cloud providers, environments, and compliance scope
• List of AWS accounts / Azure subscriptions / GCP projects and owners
• Decision on new vs existing VPCs/VNets and high-level network design
• EKS/AKS/GKE strategy (create new vs integrate with existing) and basic requirements
• Cloud IAM approach (roles/service accounts) and security approver identified
• SSO/IdP information and RBAC model for DuploCloud users
• Inventory of existing Terraform/IaC and CI/CD pipelines
• Regulatory frameworks in scope and any upcoming audits
• Short list of pilot applications and their dependencies
• Named owners for platform, networking, security, and app teams
• (Optional) On-prem Kubernetes details if using DuploCloud on-prem

Coming to onboarding with these items ready enables DuploCloud’s automation and compliance features to start delivering value on day one—and reduces the need for rework across accounts, VPCs, EKS/AKS/GKE clusters, IAM, and your existing Terraform.