Migrating from AWS to Edge

Reasons to 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: 988 edge locations mean users often get lower latency than routing through AWS regions.

Planning your migration#

Map your current AWS usage to Edge equivalents:

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 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 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 the CDN#

Create an Edge CDN deployment pointing to your existing origin (AWS or elsewhere). Add your domain, configure SSL, and test. You can run the CDN in front of your AWS origin initially as a 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, for example 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.

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: the permission model is simpler, and 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.