Migrate from AWS to Arxentra Step by Step: EC2, RDS, S3, Route 53, and IAM

Published 18 min read
awsmigrationcloudec2rdspostgresqldnsrbac

Migrating from AWS to Arxentra can cut infrastructure costs substantially while simplifying operations: the worked example in our migration cost calculator guide goes from $857 to $232 per month, a 73% reduction, though your result depends on your workload. This guide walks through every migration step: replacing EC2 instances with Arxentra VPS, moving RDS databases to managed PostgreSQL, transitioning S3 buckets to a third-party S3-compatible object store, switching Route 53 DNS to Arxentra DNS, and mapping IAM policies to RBAC roles. Each section includes tested commands and rollback procedures.

According to Flexera's 2026 State of the Cloud report, 73% of organizations overspend on AWS by an average of 35%. Teams with fewer than 50 engineers spend 18 hours per week managing AWS complexity that could be eliminated with a simpler platform. The median AWS-to-alternative migration takes 2-6 weeks depending on service count.

---

Migration Planning and Assessment

Before touching any infrastructure, inventory every AWS service your application depends on. The goal is a complete dependency map that prevents surprises during migration.

AWS Service Inventory Checklist

AWS ServiceArxentra EquivalentMigration ComplexityDowntime Required

EC2 instancesArxentra VPSMedium5-15 minutes
RDS PostgreSQLManaged PostgreSQLMedium2-10 minutes
RDS MySQLManaged MySQLMedium2-10 minutes
S3 bucketsThird-party S3-compatible store (e.g. Cloudflare R2)LowZero
Route 53Arxentra DNSLowZero (TTL-based)
IAM users/rolesRBAC rolesLowZero
CloudFrontCDN integrationLowZero
ELB/ALBBuilt-in load balancerLowDuring cutover
CloudWatchIntegrated monitoringLowZero
SESSMTP integrationLowZero

<h1>Export your current AWS resource inventory</h1>

aws resourcegroupstaggingapi get-resources \

--output json > aws-inventory.json

<h1>List all EC2 instances with details</h1>

aws ec2 describe-instances \

--query "Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,State:State.Name,AZ:Placement.AvailabilityZone}" \

--output table

<h1>List all RDS instances</h1>

aws rds describe-db-instances \

--query "DBInstances[].{ID:DBInstanceIdentifier,Engine:Engine,Size:DBInstanceClass,Storage:AllocatedStorage}" \

--output table

<h1>List S3 buckets with sizes</h1>

for bucket in $(aws s3api list-buckets --query "Buckets[].Name" --output text); do

size=$(aws s3 ls s3://$bucket --recursive --summarize | tail -1)

echo "$bucket: $size"

done

---

Step 1: EC2 to Arxentra VPS Migration

EC2 instances map directly to Arxentra VPS instances. The key difference is pricing transparency: Arxentra bills compute by usage at published per-vCPU and per-GB-of-RAM hourly rates, with 100 GB of bandwidth free each month.

Size Mapping

EC2 Instance TypevCPURAMArxentra Usage-Based Cost (24/7)

t3.micro21 GB~$14.60/mo
t3.small22 GB~$17.52/mo
t3.medium24 GB~$23.36/mo
t3.large28 GB~$35.04/mo
t3.xlarge416 GB~$70.08/mo
m5.large28 GB~$35.04/mo
c5.xlarge48 GB~$46.72/mo

*Costs use the vCPU ($0.008/hr) and RAM ($0.004/GB-hr) rates on the Pricing page for an instance running all month, at list usage rates, before any included plan hours or bundle discounts. Compare against your own EC2 bill for the region and purchase option you use.*

Application Migration Process

<h1>On your EC2 instance: create a snapshot of your application</h1>

tar -czf app-backup.tar.gz /var/www/myapp \

--exclude=node_modules \

--exclude=.git \

--exclude="*.log"

<h1>Export your environment variables</h1>

printenv

grep -E "^(APP_DB_REDIS_
API_)" > env-export.txt

<h1>Transfer to Arxentra VPS</h1>

scp app-backup.tar.gz user@your-arxentra-vps:/home/user/

scp env-export.txt user@your-arxentra-vps:/home/user/

<h1>On Arxentra VPS: restore application</h1>

ssh user@your-arxentra-vps

sudo mkdir -p /var/www/myapp

sudo tar -xzf /home/user/app-backup.tar.gz -C /

cd /var/www/myapp && npm install --production

For containerized workloads, export your Docker images and re-deploy on Arxentra. Check our Services Overview for supported container runtimes and orchestration options.

---

Step 2: RDS to Managed PostgreSQL

Arxentra managed PostgreSQL uses CloudNativePG under the hood and runs as a single instance. It does not take automated backups or offer point-in-time recovery, so schedule your own `pg_dump` to storage you control. The migration uses standard `pg_dump` and `pg_restore` with minimal downtime.

<h1>On your current environment: dump the RDS database</h1>

pg_dump \

--host=your-rds-endpoint.rds.amazonaws.com \

--port=5432 \

--username=your_user \

--format=custom \

--no-owner \

--no-acl \

--verbose \

your_database > database-backup.dump

<h1>Restore to Arxentra managed PostgreSQL</h1>

pg_restore \

--host=your-db.arxentra.cloud \

--port=5432 \

--username=app_user \

--dbname=your_database \

--no-owner \

--no-acl \

--verbose \

database-backup.dump

<h1>Verify row counts match</h1>

psql -h your-db.arxentra.cloud -U app_user -d your_database \

-c "SELECT schemaname, relname, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC;"

Minimizing Downtime During Database Migration

For databases under 50 GB, the dump-and-restore approach typically completes in under 10 minutes. For larger databases, use logical replication to sync continuously before cutting over.

  • Set up logical replication from RDS to Arxentra PostgreSQL
  • Let the replica catch up (monitor replication lag)
  • Stop writes to the source database
  • Verify replica is fully synced
  • Update application connection strings
  • Resume writes on the new database
  • This approach reduces downtime to under 60 seconds for databases of any size.

    ---

    Step 3: S3 to Object Storage

    Arxentra does not host object storage, so move your buckets to a third-party S3-compatible object store such as Cloudflare R2. Because it speaks the S3 API, your existing SDKs and tools work with a simple endpoint change, and your Arxentra services reach it over HTTPS like any other API.

    <h1>Install rclone for efficient transfer</h1>
    

    curl https://rclone.org/install.sh | sudo bash

    <h1>Configure source (AWS S3)</h1>

    rclone config create aws-s3 s3 \

    provider=AWS \

    access_key_id=$AWS_ACCESS_KEY \

    secret_access_key=$AWS_SECRET_KEY \

    region=us-east-1

    <h1>Configure destination (third-party S3-compatible store, e.g. Cloudflare R2)</h1>

    rclone config create r2 s3 \

    provider=Cloudflare \

    endpoint=https://<account-id>.r2.cloudflarestorage.com \

    access_key_id=$R2_ACCESS_KEY \

    secret_access_key=$R2_SECRET_KEY

    <h1>Sync with progress tracking</h1>

    rclone sync aws-s3:my-bucket r2:my-bucket \

    --progress \

    --transfers=16 \

    --checkers=32 \

    --log-file=migration.log

    ---

    Step 4: Route 53 to Arxentra DNS

    Export your Route 53 hosted zone records and import them into Arxentra DNS. Use low TTLs before migration to enable fast rollback.

    <h1>Export Route 53 records</h1>
    

    aws route53 list-resource-record-sets \

    --hosted-zone-id Z1234567890 \

    --output json > route53-records.json

    <h1>Convert and import to Arxentra (use the Arxentra CLI)</h1>

    arxentra dns import --file route53-records.json --zone example.com

    Set TTL to 60 seconds 48 hours before migration. After confirming everything works on Arxentra, increase TTL back to 3600 seconds. See our Documentation for detailed DNS management guides.

    ---

    Step 5: IAM to RBAC Mapping

    AWS IAM ConceptArxentra RBAC EquivalentNotes

    IAM UserTeam MemberEmail-based identity
    IAM GroupRoleOwner, Admin, Member
    IAM PolicyPermission SetResource-scoped
    IAM Role (service)Service AccountAPI key-based
    MFA2FATOTP supported

    Arxentra RBAC is intentionally simpler than IAM. Most teams need three roles: Owner (full access, including billing and team management), Admin (deploy and manage services), and Member (standard team access). This covers 95% of use cases without the complexity of writing JSON policy documents.

    ---

    Post-Migration Validation Checklist

    • [ ] All application endpoints responding correctly
    • [ ] Database queries returning expected results
    • [ ] Object storage files accessible via application
    • [ ] DNS resolving to new infrastructure
    • [ ] SSL certificates valid and auto-renewing
    • [ ] Monitoring and alerting configured
    • [ ] Backup schedules verified
    • [ ] Team members have correct RBAC access
    • [ ] Old AWS resources tagged for decommission (do not delete immediately)
    • [ ] Cost comparison documented for stakeholders

    Keep your AWS account active for 30 days after migration as a rollback safety net. Review Pricing to confirm your expected monthly costs match actual billing.

    ---

    Frequently Asked Questions

    How long does a typical AWS-to-Arxentra migration take?

    Most teams complete migration in 1-3 weeks. Simple applications with a single EC2 instance and RDS database migrate in 1-2 days. Complex setups with multiple services, large databases, and custom networking take 2-4 weeks including testing.

    Can I run on both AWS and Arxentra simultaneously during migration?

    Yes. The recommended approach is running both platforms in parallel during migration. Use DNS-based traffic shifting to gradually route users to Arxentra infrastructure while keeping AWS as a fallback.

    What about AWS services that do not have a direct Arxentra equivalent?

    Services like Lambda, SQS, and DynamoDB require architectural changes. Lambda functions can be containerized and deployed as services on Arxentra. SQS can be replaced with self-hosted Redis queues or RabbitMQ. DynamoDB workloads typically migrate to MongoDB or PostgreSQL JSONB.

    Will my application performance change after migration?

    Most applications see equivalent or better performance. Arxentra VPS instances use NVMe SSDs and dedicated CPU allocations rather than burstable credits. Database performance is typically 10-20% better due to optimized PostgreSQL configurations.

    How do I handle AWS-specific SDK calls in my application code?

    Replace AWS SDK calls with S3-compatible client libraries for object storage. For other services, use standard protocols (PostgreSQL wire protocol, SMTP, HTTP) instead of AWS-proprietary APIs. This also eliminates vendor lock-in for future platform changes.

    What cost savings should I expect?

    It depends on your workload. In the worked example in our migration cost calculator guide, a 3-instance stack with a Multi-AZ RDS database drops from $857 to $232 per month, a 73% reduction. The biggest savings there come from the managed database, having no NAT gateway fees, and lower data transfer rates ($0.05/GB after 100 GB free, versus $0.09/GB on AWS). Visit Pricing for a detailed comparison.