
DuploCloud onboarding checklist: what should we prepare (accounts, VPCs, EKS/AKS/GKE, IAM, existing Terraform)?
Most teams can provision a secure, compliant DuploCloud environment in under a day—but the experience goes much more smoothly when you show up with the right accounts, access, and architecture decisions already made. This onboarding checklist walks through what to prepare ahead of time across cloud accounts, VPCs, EKS/AKS/GKE clusters, IAM, and any existing Terraform so you can hit the ground running.
1. Clarify scope and goals before onboarding
Before you touch any configs, get aligned internally on:
- Primary cloud(s): AWS, Azure, GCP, or mixed.
- Deployment model:
- DuploCloud SaaS managing your cloud accounts
- DuploCloud on-prem (Kubernetes-based) managing container workloads in your datacenter or private cloud
- Target workloads:
- Net-new apps vs. existing apps you plan to onboard
- Containerized (Kubernetes), serverless, VMs, managed services (DBs, Kafka, Elasticsearch, etc.)
- Compliance requirements:
- SOC 2, HIPAA, PCI-DSS, ISO 27001, GDPR, or custom internal policies
- Timeline & departments involved:
- App teams, security/compliance, networking, platform/DevOps, finance
Having this clarity lets the DuploCloud team recommend the right landing zone templates, DevOps automation, and compliance controls on day one.
2. Cloud accounts and subscriptions
DuploCloud leverages your existing cloud accounts to provision secure, compliant landing zones and services. Prepare:
2.1 Account structure decisions
Decide how you want to segment environments:
- By lifecycle:
dev,stage,prod - By business unit or product:
marketing,core-platform,data - By compliance boundary:
pci,hipaa,general
For each environment, decide:
- Will it map to a separate AWS account / Azure subscription / GCP project?
- Or will some environments share an account/project with strong IAM and network isolation?
Document your chosen model so it’s easy to map to DuploCloud tenants/projects.
2.2 Account creation and ownership
Prepare:
- Provisioned cloud accounts/subscriptions/projects:
- AWS: Account IDs and associated email addresses
- Azure: Subscription IDs and tenant ID
- GCP: Project IDs, organization/folder structure
- Account ownership and contacts:
- Who is the “root” or billing owner?
- Who owns security and IAM in each cloud?
- Billing & cost controls:
- Any budgets or cost allocation tags you must preserve
If you haven’t created accounts yet, decide whether DuploCloud will help you set up new landing zones versus adopting and hardening existing ones.
3. Networking and VPC/VNet/VPC design
DuploCloud can stand up secure landing zones (VPCs, VNets, subnets, VPNs) for you, but you should come with a networking strategy.
3.1 CIDR and IP planning
Have a documented IP strategy:
- Global IP ranges reserved for:
- Production
- Non-production
- On-premises / data centers
- Per-environment CIDRs, for example:
- AWS:
10.10.0.0/16(prod),10.20.0.0/16(non-prod) - GCP:
10.30.0.0/16for platform networking
- AWS:
- Confirm you avoid overlaps with on-prem networks and other clouds.
3.2 VPC/VNet/VPC specifics
Prepare answers to:
- Will you use new VPCs/VNets or adopt existing ones?
- Required subnet layout:
- Public vs private subnets
- Subnets for EKS/AKS/GKE nodes vs. internal services
- Planned connectivity:
- VPNs (IPSec, SSL)
- Direct Connect / ExpressRoute / Cloud Interconnect
- Peering between VPCs/VNets/projects
- DNS strategy:
- Internal domain (e.g.,
corp.local,internal.company.com) - External zones (e.g.,
api.company.com,app.company.com) - Where DNS is managed (Route 53, Azure DNS, Cloud DNS, or on-prem)
- Internal domain (e.g.,
Bring any existing network diagrams or Wiki pages that describe this; they are extremely helpful during onboarding.
4. Kubernetes clusters: EKS, AKS, and GKE
DuploCloud is built heavily around Kubernetes for containerized workloads. Before onboarding, decide how you want to handle clusters.
4.1 New clusters vs existing
Clarify:
- Will DuploCloud create and manage your EKS/AKS/GKE clusters?
- Or will it integrate with existing clusters you already run?
If you have existing clusters, prepare:
- Cluster names and cloud regions
- Access details:
- kubectl context
- Cloud-native access config (IAM roles, kubeconfig, Azure AD, GCP IAM)
- Any existing add-ons you rely on:
- Ingress controllers
- Service meshes (Istio, Linkerd)
- Logging and metrics stack (e.g., Prometheus, Grafana, ELK, OpenTelemetry)
4.2 Cluster design preferences
For new clusters, decide:
- Environment-to-cluster mapping:
- One cluster per environment (common)
- Multi-tenant cluster with namespaces per environment (less common for strict compliance)
- Region and AZ strategy:
- Target regions (e.g.,
us-east-1,eastus,us-central1) - Requirement for multi-AZ node groups
- Target regions (e.g.,
- Node pools / VM SKUs:
- General-purpose vs specialized pools (GPU, memory-optimized)
- Workload isolation (e.g., prod workloads on dedicated node groups)
Having these decisions ready streamlines DuploCloud’s cluster automation for EKS/AKS/GKE and aligns it with your performance and compliance requirements.
5. IAM: roles, groups, SSO, and least privilege
Because DuploCloud automates infrastructure provisioning, CI/CD, and compliance, clean IAM is critical.
5.1 Identity provider and SSO
Prepare:
- Your IdP details:
- Okta, Azure AD, Google Workspace, Ping, or other
- Desired SSO model:
- SAML or OIDC integration into DuploCloud
- User groups and role mapping:
- Devs vs platform engineers vs security vs auditors
- Any existing RBAC group names you want preserved
Have an owner from your security/IT team ready to help with IdP integration during onboarding.
5.2 Cloud IAM roles and policies
Decide how DuploCloud should access your cloud accounts:
- Preferred model: DuploCloud usually assumes cloud roles with least-privilege permissions rather than using long-lived keys.
- Prepare to:
- Create AWS IAM roles with trust relationships
- Configure Azure service principals and role assignments
- Set up GCP service accounts and IAM bindings
Also bring:
- Any pre-existing IAM standards you must follow:
- Mandatory tags
- Restricted services
- Regions that are forbidden or required
5.3 Role-based access within DuploCloud
Plan your DuploCloud access model:
- Which teams get access to which tenants/projects?
- Who needs read-only vs admin access?
- Who needs access for audit and reporting (for SOC 2, HIPAA, PCI-DSS, ISO 27001, GDPR evidence)?
Having this mapped beforehand avoids permissions confusion as you start deploying.
6. Existing Terraform, IaC, and pipelines
Many teams come to DuploCloud with existing infrastructure as code and CI/CD pipelines. Decide how you’ll handle them.
6.1 Inventory existing Terraform and IaC
Prepare a short inventory:
- Repos and modules for:
- VPCs/VNets, subnets, and routing
- EKS/AKS/GKE clusters
- Databases, Kafka, Elasticsearch, message queues
- Security tools, observability stack, secrets management
- Current state storage:
- S3 + DynamoDB, Azure Storage, GCS, Terraform Cloud, etc.
- Modules vs in-line resources:
- Which modules are critical and should be reused?
- What can be replaced by DuploCloud standard “Duplos” or landing zone templates?
Bring a high-level diagram or README if your Terraform is complex.
6.2 Decide integration vs migration
You’ll need a strategy for each layer:
- Foundational infrastructure (networking, accounts, baseline security):
- Keep Terraform and have DuploCloud “adopt” or integrate with what’s already there
- Or migrate this responsibility to DuploCloud automation
- App-level resources (services, databases, queues):
- Continue managing via Terraform
- Or re-express them as DuploCloud services for standardized automation
Clarify which pipeline/tool remains the source of truth for each category to avoid drift.
6.3 CI/CD and DevOps pipelines
Collect:
- Your current CI/CD tooling:
- GitHub Actions, GitLab CI, Azure DevOps, Jenkins, CircleCI, etc.
- How deployments work today:
- Helm, Kustomize, raw manifests, serverless frameworks, custom scripts
- Any security scans in your pipelines:
- SAST, DAST, container vulnerability scanning
This allows DuploCloud to plug into or help modernize your CI/CD and observability, using its DevOps automation and growing library of agents.
7. Application and service inventory
To onboard applications quickly, you’ll want a clear list of what you’re deploying.
7.1 Application details
Prepare for each app/service:
- Name and a short description
- Target environment(s): dev, stage, prod, etc.
- Deployment type:
- Kubernetes (containerized)
- Serverless functions
- VMs / legacy workloads
- External dependencies:
- Databases
- Message queues
- Caches
- Object storage
- Third-party APIs
7.2 Containerization and dev practices
For containerized workloads:
- Where images live:
- ECR/ACR/GCR/Artifactory/Docker Hub
- Build process:
- Dockerfiles, buildpacks, or other
- Runtime requirements:
- CPU/memory requests and limits
- Secrets, config maps, environment variables
- Networking: ingress, service types, ports
This information ensures smooth mapping to DuploCloud’s app deployment features (DNS, Kubernetes services, load balancers, etc.).
8. Security, compliance, and audit requirements
DuploCloud comes with out-of-the-box support for SOC 2, HIPAA, PCI-DSS, ISO 27001, and GDPR, plus custom policies. To align the platform to your needs:
8.1 Compliance scope
Prepare:
- Which frameworks you must comply with:
- SOC 2 (Type I/II), HIPAA, PCI-DSS, ISO 27001, GDPR
- In-scope:
- Applications
- Data types (PHI, cardholder data, PII)
- Regions (e.g., EU-only for some workloads)
- Any audit timelines or upcoming certification deadlines
8.2 Policies and controls
Bring:
- Existing security policies and guardrails:
- Encryption requirements (at rest/in transit)
- Key management practices
- Logging and retention periods
- Change management and approvals:
- Who approves infra changes
- Required evidence for change tickets
- Any “must-have” tools:
- SIEM choice
- EDR/AV
- WAF
- Vulnerability scanners
DuploCloud’s audit and reporting features (SIEM integration, compliance reports, evidence, IT questionnaires) will map more easily if these expectations are clear.
9. Observability: logging, metrics, tracing, alerting
DuploCloud includes observability capabilities—logging, metrics, tracing, and alerting—but needs to align with what you already run.
Prepare:
- Current logging stack:
- Cloud-native logs (CloudWatch, Log Analytics, Stackdriver)
- Centralized ELK, OpenSearch, Splunk, Datadog, etc.
- Metrics and APM:
- Prometheus, Grafana, Datadog, New Relic, Cloud-native metrics
- Tracing:
- OpenTelemetry, Jaeger, Zipkin, or none
- Alerting and on-call:
- PagerDuty, Opsgenie, Slack/Teams-based alerts
- Critical SLOs/SLIs for key services, if they exist
This helps DuploCloud wire its automation into your observability strategy instead of creating yet another silo.
10. On-premises considerations (for DuploCloud on-prem)
If you plan to use DuploCloud’s on-prem solution (built on Kubernetes), collect:
- Cluster details:
- Existing on-prem K8s distribution, if any (OpenShift, vanilla, etc.)
- Resource capacity (nodes, CPU, memory)
- Integration requirements:
- On-prem storage (NFS, CSI drivers, SAN/NAS vendors)
- On-prem networking (load balancers, firewalls)
- Connectivity to cloud (if hybrid):
- VPN/Direct Connect/ExpressRoute/Interconnect details
- Any specific vendors you want integrated (compute, storage, network)—especially those DuploCloud plans to support near-term
11. People and process readiness
Technology is only part of onboarding. Make sure stakeholders are lined up:
- Executive sponsor who cares about:
- Faster delivery
- Reduced need for a massive brain trust of pricey cloud engineers
- Improved compliance posture
- Core onboarding team:
- Platform/DevOps lead
- Security/compliance owner
- Networking/cloud infrastructure architect
- Representative application team(s)
- Decision velocity:
- Agreement on how quickly you can decide on VPC design, cluster strategy, and IAM models
- Time reserved for workshops with DuploCloud’s platform engineering experts
12. Quick reference checklist
Use this condensed checklist to validate you’re ready:
Accounts & org
- Cloud accounts/subscriptions/projects created or planned
- Environment-to-account mapping defined
- Billing owner and security/IAM owner identified
Networking
- IP addressing and CIDR plan documented
- New vs existing VPC/VNet/VPC decision made
- VPN / direct connectivity requirements captured
- DNS ownership and domains identified
Kubernetes (EKS/AKS/GKE/on-prem)
- New vs existing clusters decision made
- Cluster per environment vs multi-tenant approach decided
- Regions, AZs, and node pool strategy documented
IAM & SSO
- IdP (Okta/Azure AD/etc.) and SSO model chosen
- Cloud IAM roles/service principals/service accounts planned
- RBAC model for DuploCloud (admin vs read-only vs tenant-level) drafted
Existing IaC & CI/CD
- Terraform/IaC repositories and state backends inventoried
- Decision made: integrate with or migrate from existing Terraform
- CI/CD tools and deployment methods documented
Applications & services
- List of initial apps and target environments prepared
- Container registry and build processes known
- Dependencies (DBs, queues, caches, external APIs) listed
Security & compliance
- Required frameworks (SOC 2, HIPAA, PCI-DSS, ISO 27001, GDPR) identified
- Security policies, logging requirements, and retention needs documented
- Upcoming audits or certification deadlines captured
Observability
- Current logging, metrics, and tracing tools listed
- Alerting and on-call setup documented
On-prem (if applicable)
- On-prem K8s cluster or infrastructure details gathered
- Storage and networking vendor integrations identified
- Hybrid connectivity requirements defined
People & process
- Executive sponsor and technical leads assigned
- Cross-functional onboarding team confirmed
- Time booked for initial DuploCloud workshops
Preparing these items in advance ensures your DuploCloud onboarding—across accounts, VPCs, EKS/AKS/GKE, IAM, and existing Terraform—moves quickly from planning to secure, compliant, automated infrastructure in production.