AWS EC2
An AMI per run — and the EBS snapshots cleaned up after it
Give VPS Snaps a scoped IAM access key and every run produces a whole-instance AMI with NoReboot set — plus the cleanup step that most home-grown backup scripts quietly skip.
Backup Jobs
Automated backup schedules
postgres-main nightly
Last run 6h ago
web-01 snapshots
Last run 9h ago
api-prod volumes
Last run 4m ago
staging-db weekly
Last run 3d ago
Connecting AWS EC2
IAM access keys
Provide an IAM access key, its secret, and the region your instances run in. Five EC2 actions are all snapshots need — no console access for the user at all. An optional second block adds recovery servers, Elastic IP failover and test restores.
In AWS IAM, create a user with an inline policy allowing exactly ec2:DescribeInstances, ec2:CreateImage, ec2:DescribeImages, ec2:DeregisterImage and ec2:DeleteSnapshot, and no console sign-in. For recovery servers, Elastic IP failover and test restores, add the second block shown on the connect screen.
Create an access key for that user under Security credentials → Access keys.
In VPS Snaps, paste the key and secret and pick the region your instances are in. Have instances in several regions? Add one connection per region.
What one connection reaches
EC2 API calls are region-scoped, so one connection covers one region — the same shape as Hetzner's one-project-per-token. Instances across three regions means three connections on one AWS account.
What one run actually produces
No proprietary format and no copy on our side. VPS Snaps makes the same API call you could make yourself, and records what AWS EC2 gave back.
AMI
CreateImage({ InstanceId, NoReboot: true })- What it covers
- Every EBS volume attached to the instance, recorded as block device mappings on the image. Data on ephemeral instance store is not part of an EBS-backed AMI.
- How consistent it is, honestly
- NoReboot is set deliberately, matching every other provider here: the instance is not restarted to be imaged. AWS's own caveat applies — no reboot means no filesystem flush, so the image is crash-consistent.
And what happens to the old ones
This is the step worth reading twice. Before deregistering an aged AMI, VPS Snaps calls DescribeImages to read its BlockDeviceMappings and collect the backing EBS snapshot IDs — there is no reliable way to find them afterwards. It then deregisters the image and deletes each snapshot individually.
Cleanup runs only after a run has already succeeded, so a failing schedule never deletes the last good copy you have. Every deletion is written into that run’s log with the date of the backup it removed.
VPS Snaps stores the ID and the name of each image it creates — never the image itself. Close your account and every copy already taken stays exactly where it is, in your AWS EC2 account.
AWS EC2 specifics worth knowing first
Every provider does this differently, and the differences are the part that bites at 3am. These are the ones that changed how the integration had to be built.
Deregistering an AMI leaves its storage behind
This is the single most expensive mistake in DIY EC2 backups. DeregisterImage removes the AMI and nothing else; the EBS snapshots that hold the actual data stay in the account and keep billing indefinitely, invisible unless you go looking. VPS Snaps reads the mappings first, deregisters, then deletes each snapshot — and records how many it removed in the run log.
The IAM policy is five actions long
ec2:DescribeInstances, ec2:CreateImage, ec2:DescribeImages, ec2:DeregisterImage, ec2:DeleteSnapshot. That is the complete list for snapshots — no S3, no IAM, no console access, nothing that can touch a running instance. The recovery block is optional, and even it can terminate only instances, and delete only security groups, that VPS Snaps tagged as its own. The exact JSON is on the connect screen, ready to paste into an inline policy.
A replacement from your newest AMI
With the recovery block, Recover now launches a new instance from the newest AMI — or a fresh Ubuntu 24.04 with the server's databases, files and software restored from its backups — in the region's default VPC, with a security group of its own opening the ports the server used. Automatic failover moves your Elastic IP to it in one call. Sizes are priced from AWS's own price list, disk included.
One connection, one region
EC2 is region-scoped at the API level, so a key that works beautifully in eu-west-1 sees nothing in us-east-1. VPS Snaps makes the region an explicit field on the connection rather than guessing, and you add a second connection for a second region.
AMI creation is the slow one
The image resource carries its own state from pending to available, so VPS Snaps polls it every 20 seconds for up to 20 minutes. AMIs are among the slowest artifacts here, and a large multi-volume instance is exactly where that ceiling matters.
FAQs
Can’t find the answer you’re looking for? Reach out to our support team.
How do I know the EBS cleanup actually happened?
The run log says so, in the run's own step-by-step history: it records that it deregistered a specific AMI along with the number of backing snapshots it deleted, and the date of the run those belonged to. If a snapshot delete fails, the AMI is still gone and the run still succeeds — a stray snapshot is a cost leak, not a data-loss event — but you can see it in the log rather than discovering it on the invoice.
Can I use an IAM role instead of a long-lived access key?
Not today. The connection stores an access key ID, a secret and a region, sealed together with AES-256-GCM, and cross-account role assumption is not implemented. The practical mitigation is the policy above: a user with five EC2 actions and no console access is a small blast radius, and the key can be rotated in IAM whenever you like. The optional recovery block widens that only to instances and security groups VPS Snaps creates and tags.
Does an AMI include my instance store or my RDS database?
No to both. An EBS-backed AMI captures the EBS volumes attached to the instance — ephemeral instance-store data is not in it, and RDS is a separate service that is not touched at all. For a managed database, point a database backup job at the RDS endpoint and get a portable dump in your own bucket instead.
Running on more than one of these?
Connections are additive and independent — a Hetzner project and an AWS region live side by side in the same workspace, on the same schedules and the same run history.
A snapshot restores a instance on AWS EC2 and nowhere else. For a copy you can carry anywhere, add a database, file or Docker job on the same instance — those write plain .tar.gz and .sql.gz into an S3-compatible bucket you own.
Everything else it does
Storage, schedules, alerts, recovery and team access, in one place. Which plan each one starts on is on the pricing page.
- Bring your own storage
- Backups land in your own S3-compatible bucket — Backblaze B2, Wasabi, Cloudflare R2, or plain S3 — or in your own Google Drive, Box, Dropbox or OneDrive. You hold the keys and the data.
- Snapshots stay with your provider
- Provider snapshots are created through the provider's own API and never leave your account. We store the snapshot ID, not the image.
- Eight providers, one dashboard
- DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Google Compute Engine and Microsoft Azure — scheduled and reviewed from the same place.
- A replacement server on demand
- Recover now builds a new server on your own DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, AWS Lightsail, Azure or Google Compute Engine account, from its snapshot or from its backups, software included.
- Failover on any cloud
- When a server stops answering, its traffic moves to the recovery server: by reserved or floating IP where your cloud has one, or by your DNS on Cloudflare, which works on every cloud.
- Know it's down, with the way back
- Uptime monitors for sites, ports and scheduled jobs confirm an outage before alerting, name the server's newest backup, and publish a status page. On paid plans.
- Your DNS zones, backed up
- Every record in a Cloudflare zone, kept in your own storage as a BIND file too. A restore previews what differs and writes back only that.
- Schedules that fit your traffic
- Hourly, daily, weekly, monthly, or a fixed interval in minutes — anchored to your timezone, so a 02:00 job stays at 02:00 across a DST change.
- Retention that prunes itself
- Set how many days to keep. Older snapshots and archives are cleaned up after each successful run, so storage bills stay flat.
- Every run on record
- Status, duration, size and trigger, with each step it took in order and its warnings and errors kept in place — so a failure tells you which step broke.
- Checksummed on upload
- Every archive is hashed as it streams to your bucket and the checksum is stored with the run, so you can verify what landed.
- Run on demand
- Trigger any job by hand before a migration or a risky deploy, without touching its schedule or its retention window.
- Alerts on five channels
- Email plus Slack, Microsoft Teams, Google Chat, and Discord — on success, on failure, and on a job that missed its schedule entirely.
- Encrypted credentials
- SSH keys, database passwords, and storage secrets are sealed with AES-256-GCM before they touch the database.
- Team access with roles
- Invite your team into a shared workspace as owner, admin, or member, so backups outlive whoever set them up.
“The biggest advantage for us is that VPS Snaps works with the infrastructure we already have instead of forcing us into a proprietary backup environment. Provider snapshots stay inside our cloud account, while database and file archives can go directly into our own bucket.”
Schedule your first AWS EC2 backup tonight.
Connect the account, pick a instance, set a schedule and a retention window. The first run is what proves the credential has the scope it needs — a much better thing to discover on a quiet evening.
No credit card required. Cancel anytime.