CloudMirror is a SaaS tool that discovers a company’s current on-premises or existing cloud infrastructure, automatically computes the equivalent cloud configuration, and provisions a matching environment on AWS or GCP in a small number of guided steps — without requiring the user to hand-author Terraform, CloudFormation, or Deployment Manager templates from scratch.

One-line pitch: Point CloudMirror at your existing environment. It figures out what you have, recommends what you need in the cloud, and stands it up for you.

Problem

Teams migrating to or expanding in AWS/GCP face three recurring pain points:

1. Discovery is manual. Engineers manually inventory servers, network topology, storage, and dependencies before they can even start sizing a cloud environment.
2. Sizing is guesswork. Choosing instance types, storage tiers, network CIDR ranges, and IAM boundaries is often based on rough estimates rather than actual utilization data.
3. Provisioning is slow and error-prone. Even with IaC tools, someone has to write and validate templates, and mistakes in networking or permissions are common and costly.

This is slow, expensive (consultants/architects), and creates configuration drift between what a company actually runs and what gets provisioned in the cloud.

Goals / Non-Goals

Goals

• Reduce time-to-provision a right-sized cloud environment from weeks to hours.
• Remove the need for deep IaC/cloud expertise to get a reasonable, secure baseline environment.
• Support both AWS and GCP from a single workflow.
• Make configuration decisions explainable — show why a given instance type or network layout was chosen.

Non-Goals (v1)

• Not a full migration tool (no automated data migration or cutover orchestration).
• Not a cost-optimization / FinOps platform (though it will surface cost estimates).
• Not multi-cloud simultaneous provisioning in v1 — one target cloud per environment.
• Not a replacement for Terraform/Pulumi for teams that want full custom IaC control (CloudMirror can export to Terraform for that audience).

Target Users

• Mid-size companies without a large dedicated cloud infrastructure team.
• Enterprise teams standing up new isolated environments (dev/test/DR) who don’t want to re-architect from scratch each time.
• Solutions architects/consultants who want to accelerate first-pass environment design for clients.

Automatic Configuration Engine

This is the core differentiator. It has three layers:

Discovery Layer

• Agents/connectors pull inventory and utilization metrics from:
  • On-prem: vCenter/ESXi, bare metal via SNMP/agent, existing config management (Ansible/Puppet inventories).
  • Existing cloud: AWS Config/Cost Explorer, GCP Asset Inventory/Cloud Monitoring.
• Captures: CPU/RAM/disk per workload, network topology and traffic patterns, storage type and IOPS, existing security groups/firewall rules, and application dependency graphs (via traffic flow analysis).

Mapping & Sizing Layer

• Translates discovered resource profiles into target cloud primitives using a rules + ML hybrid model:
  • Rule-based baseline: maps CPU/RAM/disk profiles to nearest-fit instance families (e.g., a VM using 4 vCPU/16GB steady-state → m6i.xlarge on AWS or n2-standard-4 on GCP).
  • Utilization-based right-sizing: uses observed peak/average utilization (not just allocated capacity) to avoid over-provisioning.
  • Network mapping: reconstructs VPC/subnet layout from discovered topology, preserving segmentation and security boundaries.
  • Compliance-aware: applies org-selected compliance profiles (e.g., HIPAA, SOC 2) that constrain instance types, encryption, and region choices.
• Outputs a proposed architecture as a structured spec (internal JSON schema), independent of cloud provider, then compiles it to either AWS or GCP resource definitions.

Provisioning Layer

• Compiles the cloud-agnostic spec into Terraform modules (one module set per provider).
• Applies via a managed Terraform run with plan/approve/apply gates.
• Tags all resources for traceability back to the source discovery run.
• Supports drift detection post-provisioning.

Architecture Overview

Key components:

• Discovery Service — lightweight agent (Go binary) + API connectors.
• Inventory Graph DB — stores topology/dependencies (e.g., Neo4j or similar).
• Sizing Engine — Python service, rules engine + trained model on utilization data.
• Spec Compiler — converts internal spec to Terraform HCL per provider.
• Orchestration Service — manages plan/apply lifecycle, state, rollback.
• Web Console — review, approve, visualize, monitor drift.

Key Features (v1 Scope)

Feature	Description
Auto-discovery agent	Read-only scan of on-prem/cloud environment
Configuration recommendation	Right-sized AWS/GCP config with rationale
Cost estimate	Projected monthly cost before provisioning
One-click provisioning	Applies Terraform-generated environment
Environment diagram	Visual before/after comparison
Drift detection	Alerts if live environment diverges from spec
Terraform export	For teams wanting to take over IaC manually
Compliance profiles	Pre-built constraint sets (HIPAA, SOC 2, PCI baseline)

Future (v2+): multi-cloud simultaneous provisioning, cost optimization recommendations, automated DR environment generation, Azure support.

Security & Access Model

• Discovery agents are read-only by default; no write access required for the analysis phase.
• Provisioning requires explicit, scoped IAM role/service account granted by the customer (least-privilege, time-boxed if possible).
• All discovered infrastructure data encrypted at rest and in transit.
• No customer data used to train shared models across tenants without explicit opt-in.

Success Metrics

• Time from “connect” to “provisioned environment” (target: under 4 hours for a standard environment).
• % reduction in manual sizing/config effort vs. baseline (survey-based).
• Accuracy of sizing recommendations (post-provision utilization vs. predicted, target within 20%).
• Environment drift incidents post-launch.