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 (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 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.networkUpdate 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.
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.