multi-cloud-deployment

# Multi-Cloud Deployment Guide RedC's core strength is deploying infrastructure across multiple clouds simultaneously. This skill covers the practical knowledge needed to work across providers — from authentication setup to region selection to cross-cloud consistency patterns. Understanding these differences matters because each cloud has its own authentication model, naming conventions, and regional availability, and getting any of these wrong means a deployment that fails at plan time. ## Provider Authentication Each cloud provider authenticates differently. Set these environment variables before running RedC, or configure them in RedC's credential profiles. | Provider | Required Environment Variables | Notes | |----------|-------------------------------|-------| | **AWS** | `AWS_ACCESS_KEY_ID` + `AWS_SECRET_ACCESS_KEY` | Or use `~/.aws/credentials` profile | | **Azure** | `ARM_SUBSCRIPTION_ID` + `ARM_TENANT_ID` + `ARM_CLIENT_ID` + `ARM_CLIENT_SECRET` | Service principal recommended | | **GCP** | `GOOGLE_APPLICATION_CREDENTIALS` (path to JSON) | Service account key file | | **Alibaba Cloud** | `ALICLOUD_ACCESS_KEY` + `ALICLOUD_SECRET_KEY` | China mainland requires real-name verification | | **Tencent Cloud** | `TENCENTCLOUD_SECRET_ID` + `TENCENTCLOUD_SECRET_KEY` | SecretId, not AccessKey | | **Huawei Cloud** | `HW_ACCESS_KEY` + `HW_SECRET_KEY` | Regional endpoints differ from global | | **Volcengine** | `VOLCENGINE_ACCESS_KEY` + `VOLCENGINE_SECRET_KEY` | ByteDance cloud platform | Note the naming inconsistency — AWS uses "access key", Tencent uses "secret id", GCP uses a JSON file. This is a common source of confusion. When helping users configure credentials, pay attention to which provider they're targeting. ## Region Selection Strategy Region choice affects latency, cost, data residency, and instance availability. Pick based on your primary constraint: **Proximity to target** (red team operations): Choose the region geographically closest to the target network. A C2 server in `ap-northeast-1` (Tokyo) communicating with targets in Japan will have much lower latency than one in `us-east-1`. **Cost minimization:** - AWS: `us-east-1` (N. Virginia) is almost always cheapest - Azure: `eastus` has the widest instance selection and lowest pricing - GCP: `us-central1` (Iowa) offers the best spot pricing - Chinese clouds: `cn-hangzhou` (Alibaba), `ap-guangzhou` (Tencent) are the primary regions with best availability **High availability:** Distribute across 2+ regions in the same provider, or across providers. RedC's multi-cloud templates make this straightforward. ## Cross-Cloud Consistency When deploying the same tool across multiple clouds, standardize these elements to reduce operational complexity: - **OS**: Use Ubuntu 22.04 LTS everywhere. It's available on all providers and most red team tools support it - **Init scripts**: Use cloud-init / `user_data` for post-deploy configuration. The syntax is identical across providers - **Naming conventions**: Use a consistent prefix like `redc-{project}-{provider}-{role}` so you can identify resources at a glance - **Instance sizing**: Each provider has different naming, but roughly equivalent tiers: | Size | AWS | Azure | GCP | Alibaba | |------|-----|-------|-----|---------| | Small (2c/4G) | `t3.medium` | `B2s` | `e2-medium` | `ecs.t6-c1m2.large` | | Medium (4c/8G) | `t3.xlarge` | `B4ms` | `e2-standard-4` | `ecs.g6.xlarge` | ## Cost Control Across Clouds Multi-cloud deployments multiply cost risk because you need to track spending across separate billing dashboards. - Use spot/preemptible instances for non-critical workloads (scanning, data processing) - Set billing alerts on every cloud account — a forgotten instance in one provider can silently drain budget - Use RedC's `get_balances` tool to check all accounts at once - Use RedC's scheduled task feature for auto-shutdown when engagements end