Migrate from AWS

Leaving AWS usually stalls on the same thing: nobody wants to hand-translate a sprawl of EC2 instances, S3 buckets, DNS records, and security groups into a new provider's console without dropping something. This playbook turns that into a conversation. Your AI assistant reads your AWS account through the aws CLI, plans the move, prices the American Cloud side, and — when you say go — builds it with the American Cloud MCP server.

The economics are why teams start: American Cloud charges zero egress fees and pricing that runs lower than the hyperscalers (see how to move your workloads off AWS). The hard part has always been the mechanics. That's what your assistant handles here.

What this playbook covers

This is the well-trodden path: the stack most small and mid-size teams actually run on AWS.

• EC2 instances → American Cloud VMs
• S3 buckets → object storage (S3-compatible)
• Route 53 zones → hosted DNS zones and records
• ELB / ALB → load balancers
• EKS clusters → managed Kubernetes
• RDS databases → PostgreSQL or MySQL on a VM

If your architecture is deeply serverless — most of your logic lives in Lambda functions, Step Functions, and event glue rather than on long-running servers — that's a different journey. The first move there is re-platforming onto a long-running server or Kubernetes; once your code runs as a service you can host anywhere, this playbook applies again. Everything below assumes workloads that run on instances, in containers, or behind a load balancer.

How it works: two credentials, one conversation

You give your assistant two things and it does the rest:

1. The aws CLI, read-only. Configure it with credentials scoped to read your AWS account (the AWS-managed ReadOnlyAccess policy is the simplest whitelist). Your assistant runs aws ec2 describe-instances, aws s3 ls, aws route53 list-hosted-zones, and similar commands to inventory the source. Nothing on AWS changes.
2. The American Cloud MCP server, for the destination. This is where resources get created. Start read-only to explore and price, then switch on writes when you're ready to build.

A coding agent like Claude Code is the ideal driver, because the migration needs a terminal as much as it needs API calls: rsync over SSH, pg_dump, rclone. The assistant provisions infrastructure and runs the data-movement commands in one session.

The phases

You don't have to cut over everything at once. The whole point is that the bill shrinks service by service — each workload you move is one line item that stops on AWS and starts (smaller) on American Cloud. The phases:

1. Inventory (read-only) — your assistant catalogs the AWS account.
2. Plan and price (read-only) — it maps each resource to an American Cloud equivalent and produces a cost estimate you compare against your AWS bill.
3. Provision — it builds the destination: networks, VMs, storage, load balancers, clusters.
4. Transfer data — buckets, disks, and databases are copied across and verified.
5. Cut over DNS — records are recreated, TTLs lowered ahead of time, then flipped.
6. Verify — traffic is on American Cloud and everything checks out.
7. Decommission — you tear down the AWS resource for that workload, and that line item is gone.

Repeat per workload. A single non-critical service first; the rest once you trust the process.

Phase 1: inventory your AWS account

Point your assistant at the read-only aws CLI and ask it to take stock. Paste this:

I'm planning to migrate from AWS to American Cloud. I've configured the aws
CLI with read-only credentials. Don't change anything on AWS — only read.
 
Inventory my AWS account and build a migration table. For each of these,
list what exists with the details I'll need to recreate it elsewhere:
 
1. EC2 instances: name/tag, instance type (vCPU + memory), region, OS, root +
   attached EBS volume sizes, and which are actually running.
2. S3 buckets: name, region, rough object count and total size, and whether
   each is public or private.
3. Route 53 hosted zones: domain, and every record (type, name, value, TTL).
4. Load balancers (ELB/ALB): listeners, target groups, and which instances
   sit behind each.
5. EKS clusters: Kubernetes version, node group sizes, and node counts.
6. RDS instances: engine (PostgreSQL/MySQL) and version, instance size, and
   storage size.
 
Summarize it as a table I can review, and flag anything that looks unusual or
that won't map cleanly to a standard VM/storage/DNS/load-balancer/Kubernetes
setup.

What your assistant will do

This phase is entirely read-only on both sides — it touches no MCP write tools and changes nothing on AWS.

1. Walk the AWS account with aws ec2 describe-instances, aws s3 ls / aws s3api, aws route53 list-hosted-zones and list-resource-record-sets, aws elbv2 describe-load-balancers, aws eks describe-cluster, and aws rds describe-db-instances.
2. Normalize the findings into instance sizes (vCPU + memory), volume sizes, bucket footprints, DNS records, and cluster shapes — the inputs the American Cloud side needs.
3. Surface the edge cases up front: anything serverless, anything with an unusual networking shape, public-vs-private buckets. Honest scoping here saves surprises later.

You finish this phase with a migration table and zero changes made anywhere.

Phase 2: plan and price the American Cloud side

Now have your assistant map the inventory to American Cloud and put a number on it — still without creating anything.

Using that inventory, propose the American Cloud equivalents and price them.
Don't create anything yet — read-only and cost estimates only.
 
For each AWS resource, map it like this:
- EC2 instance  -> a VM with matching vCPU/memory and disk
- S3 bucket     -> an object storage unit + bucket
- Route 53 zone -> a hosted DNS zone with the same records
- ELB/ALB       -> a load balancer rule with the same backends
- EKS cluster   -> a managed Kubernetes cluster of similar size
- RDS instance  -> PostgreSQL/MySQL installed on a VM sized for it
 
Pick a region close to my current AWS region. For every compute resource,
call the matching cost-estimate tool and give me a total monthly estimate for
the American Cloud side. I'll compare it against my AWS bill.

What your assistant will do

1. Choose sizes and a region. It calls list_regions, list_vm_packages, list_images, and list_kubernetes_packages to find equivalents — a VM tier whose CPU/memory bracket the EC2 instance, a Kubernetes node package matching the EKS node group, an Ubuntu image for the RDS-replacement VM.
2. Price every piece without building it. The MCP server exposes cost-estimate tools that take the same arguments as the create tools: get_cost_estimate_vm, get_cost_estimate_object_storage, get_cost_estimate_kubernetes, and others. The assistant calls these to assemble a monthly total. Nothing is billed.
3. Hand you the comparison. You get an American Cloud monthly estimate to set against your current AWS bill — including the egress line, which on American Cloud doesn't exist: there are no egress fees.

Phase 3 onward: execute one phase at a time

With the plan priced and writes enabled, drive the build phase by phase. Run each as its own prompt so you can review between steps — this keeps you in control and lets the assistant pause for confirmation on anything irreversible.

Let's execute the migration plan. Do it one phase at a time and stop for my
confirmation between phases. We have a read-write key and writes are enabled.
 
Phase 3 — provision the destination:
- Create the network(s), then the VMs that replace my EC2 instances (matching
  sizes), each with my SSH key and the right inbound ports open.
- Create the object storage unit and buckets that replace my S3 buckets.
- If I have an EKS cluster, create the equivalent managed Kubernetes cluster.
- For my RDS database, create a VM sized for it and install PostgreSQL (or
  MySQL) over SSH, listening only on localhost.
Show me the cost estimate for anything new before you create it, and report
the IPs and identifiers when each is up.
 
When I confirm, move to Phase 4 (data transfer): start the S3 bucket copy
first, then the EC2 disk data, then the database dump and restore.

What your assistant will do

Provision (Phase 3). Grounded in real MCP tools:

• Networks and VMs. It creates an isolated network if needed, then create_vm for each EC2 replacement — passing keypairs (after checking list_ssh_keys or making one with create_ssh_key) and networkAccess to open the inbound ports your instances actually use. It polls get_vm until each reaches STARTED with a public IP.
• Object storage. create_object_storage_unit and create_object_storage_bucket stand up the S3 replacements; get_object_storage_keys returns the access key, secret, and endpoint for the transfer step.
• Kubernetes. create_kubernetes_cluster (sized from list_kubernetes_packages, version from list_kubernetes_versions) builds the EKS equivalent; get_kubernetes_cluster_config later returns the kubeconfig so you can apply your manifests. See run on Kubernetes for the full recipe.
• The RDS replacement. It creates a VM and, over SSH, installs PostgreSQL or MySQL bound to localhost so the database isn't exposed to the internet — the same pattern as the database-on-a-VM step in the Next.js recipe.

Transfer data (Phase 4). This is the heart of the move, and order matters — S3 goes first.

• S3 → object storage. Because both ends speak S3, the assistant uses rclone to sync bucket-to-bucket: an AWS remote on one side, an American Cloud remote (the keys from get_object_storage_keys) on the other. American Cloud charges nothing to receive the data, so only AWS's egress applies. When the sync completes, it compares object counts and checksums before anything is removed from AWS. For the S3 wiring details, see object storage with your AI assistant.
• EC2 disk data → VM. It rsyncs application files, configs, and data directories from each EC2 instance to its replacement VM over SSH, then installs and starts the services so the new VM mirrors the old.
• RDS → PostgreSQL/MySQL on a VM. It runs pg_dump (or mysqldump) against the RDS endpoint, transfers the dump, and restores it into the database on the new VM, then updates the application's connection string to point at localhost (or the private network).

Phase 5: cut over DNS with a low TTL

DNS is what actually moves your traffic, so it's deliberate and reversible.

Phase 5 — DNS cutover. First, the records serving traffic today live on Route
53, so tell me exactly which TTLs to lower there (down to 60-300 seconds) and
I'll make that one change in the AWS console; then we wait for the old TTL to
expire so changes propagate fast. Meanwhile, recreate my Route 53 zone and
records on American Cloud DNS with short TTLs. When I confirm the new servers
respond correctly, switch the A/CNAME records to the new IPs. Keep the old AWS
resources running until I've verified the cutover.

What your assistant will do

1. Lower TTLs where DNS is served today. The records currently answering queries live on Route 53, so that's where TTLs must drop ahead of the flip — the one deliberate change to make on the AWS side (do it yourself in the console, or grant the assistant that single write). Wait out the old TTL before cutting over.
2. Recreate the zone and records. create_dns_zone for the domain, then create_dns_record for each record from the Route 53 inventory — same names, types, and values, created with short TTLs from the start (update_dns_record adjusts them later). You'll point your registrar's nameservers at American Cloud when you're ready; the assistant shows you which to set, and that delegation change itself can take a few hours to propagate.
3. Switch the targets only on your go-ahead, pointing the A and CNAME records at the new VM and load-balancer IPs.

For load balancers specifically, it uses reserve_public_ip, create_load_balancer_rule (with the algorithm and ports matching your ELB/ALB listeners), and assign_vms_to_load_balancer to put the new VMs behind it — the DNS record then points at the load balancer's IP. See DNS management and load balancers for the underlying concepts.

Phase 6: verify

Before you tear anything down on AWS, confirm the new stack is serving real traffic.

Phase 6 — verify. Confirm DNS now resolves to the American Cloud IPs, that the
sites/apps respond over HTTPS, that both backends are attached to the load
balancer and their VMs are running,
and that the app can reach its database. Spot-check that a few known S3 objects
exist in the new buckets with matching sizes. Give me a go/no-go summary.

Your assistant checks resolution, hits the endpoints, confirms load-balancer backends are healthy, verifies the app reaches its migrated database, and re-checks a sample of object-storage keys against the source. You get a clear go/no-go before committing.

Phase 7: decommission, one service at a time

Once a workload is verified on American Cloud, retire its AWS counterpart — and that line item disappears from your AWS bill. Because you've moved service by service, there's no big-bang switchover and no moment where everything is in flight at once.

Phase 7 — decommission. I've verified [this workload] on American Cloud.
Walk me through retiring its AWS resources safely: confirm nothing else still
depends on them, then give me the exact aws CLI commands to terminate the EC2
instance / delete the bucket / remove the load balancer. I'll run the destructive
AWS commands myself after I review them.

Deletions on AWS stay in your hands — the assistant proposes the commands and confirms there are no remaining dependencies, but you run anything destructive on the source. Repeat the whole cycle for the next workload. Each pass, the AWS bill gets smaller and the American Cloud side carries more, until the migration is simply done.

Next steps

• MCP server overview — setup, read-only-by-default safety, and the read-write key you need for the build phases.
• Object storage with your AI assistant — the S3-compatible details behind the bucket transfer.
• Run on Kubernetes — the full recipe for the EKS-equivalent cluster.
• Deploy a Next.js app — including the database-on-a-VM pattern used for RDS replacement.
• Write an AGENTS.md for your project — teach your assistant your conventions so future moves and deploys are one prompt.
• How to move your workloads off AWS and egress fees explained — the economics that make the case.