---
title: "Migrating from AWS to Edge"
description: "Step-by-step guide to migrating from AWS to Edge Network: DNS, storage, CDN, and compute. Zero egress fees, simpler pricing, and no vendor lock-in."
url: https://edge.network/academy/migrating-from-aws/
---

# Migrating from AWS to Edge

[Back to Academy](https://edge.network/academy)
Featured Guide
15 min read

# Migrating from AWS to Edge

How to migrate your infrastructure from AWS to Edge Network: DNS, storage, CDN, and compute — with zero egress fees and simpler pricing.

## Why migrate?

Edge offers several practical advantages over AWS for many workloads:

- **Zero egress fees** — No charges for data leaving the network. AWS egress costs can add up quickly; Edge does not charge for egress.
- **Simpler pricing** — Flat, predictable rates for CDN, compute, storage, and DNS. No region-specific pricing tables or surprise billing.
- **No vendor lock-in** — Standard protocols (S3-compatible storage, HTTP origins). Move data in and out without proprietary APIs.
- **Better performance in many regions** — 2,200+ edge locations mean users often get lower latency than routing through AWS regions.

## Planning your migration

Map your current AWS usage to Edge equivalents:

- **EC2** → [Edge Compute](https://edge.network/compute) (VMs)
- **CloudFront** → Edge CDN
- **Route 53** → Edge DNS
- **S3** → Edge Storage (S3-compatible API)

Assess which services you actually use. Many workloads only need CDN and storage; compute migration
is more involved. Start with the lowest-risk components — typically DNS and CDN — then move storage
and compute.

## Step-by-step migration

### 1. Set up your Edge account

Create an account at edge.network, install the CLI, and configure your API key.
See the [First Deployment](https://edge.network/academy/first-deployment) guide for setup.

### 2. Migrate DNS first (lowest risk)

Create your zone in Edge DNS and replicate your records from Route 53. Lower TTLs 24–48 hours
before cutover to minimise propagation delay. Switch nameservers when ready. DNS cutover is
reversible — you can point back to Route 53 if needed.

### 3. Move storage

[Edge Storage](https://edge.network/storage) is S3-compatible. Use the AWS CLI with `--endpoint-url`
to sync buckets:

```
aws s3 sync s3://your-aws-bucket s3://your-edge-bucket \
  --endpoint-url https://storage.edge.network
```

Update your application to use the Edge Storage endpoint. If your app already uses the S3 API,
change the endpoint and credentials; the code stays the same.

### 4. Set up CDN

Create an Edge CDN deployment pointing to your existing origin (AWS or elsewhere). Add your domain,
configure SSL, and test. You can run CDN in front of AWS origin initially — a useful hybrid
step — then switch the origin to Edge Storage or an Edge VM once ready.

### 5. Migrate compute last (most complex)

Spin up Edge VMs, migrate your application code and data, configure networking, and test.
Use load balancing or multiple VMs if you need redundancy. Cut over traffic gradually —
e.g. by shifting a percentage of users or a subset of regions.

## Cost comparison and what's different

Edge pricing is straightforward: no egress fees, no region-specific multipliers, no IAM complexity.
You pay for usage (GB stored, requests served, compute hours) at flat rates. Compare your AWS bill
— especially egress and data transfer — against [Edge's pricing page](https://edge.network/pricing).

**What's simpler:** No IAM policies, no VPC configuration, no region-specific pricing.
Deploy and scale without wrestling with AWS's organisational layers.

## What Edge doesn't have... yet

Honesty matters. Edge does not yet offer everything AWS does:

- **Lambda / serverless** — Not available. Use Edge VMs for compute-heavy or long-running workloads.
- **Managed databases** — No RDS equivalent. Run your own database on a VM, or use an external managed service.
- **IAM policies** — Permission model is simpler; fine-grained IAM is not available.

If your stack depends on Lambda, RDS, or complex IAM, a full migration may not be viable today.
Consider a hybrid approach: use Edge for CDN, storage, and DNS; keep AWS for serverless or managed
databases until Edge expands its offerings.

## Next steps

[Cost Optimisation](https://edge.network/academy/cost-optimization) [First Deployment](https://edge.network/academy/first-deployment)