AWS Lightsail
The whole instance in one snapshot, and one call to remove it
Give VPS Snaps an IAM access key with Lightsail's five snapshot actions, and every run keeps a snapshot of the whole instance, its system disk and attached disks, inside your own AWS account.
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 Lightsail
IAM access keys
Provide an IAM access key, its secret, and the region your Lightsail instances run in. Five Lightsail actions are all snapshots need, and no console access for the user at all. An optional second block adds recovery servers and test restores.
In AWS IAM, create a user with no console sign-in and an inline policy allowing exactly lightsail:GetInstances, lightsail:CreateInstanceSnapshot, lightsail:GetInstanceSnapshot, lightsail:DeleteInstanceSnapshot and lightsail:TagResource. For recovery servers 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, choose AWS Lightsail, paste the key and secret, and pick the region your instances are in. Instances in several regions need one connection per region.
What one connection reaches
Lightsail's API is region-scoped, like EC2's, so one connection covers the instances in one region. It is also separate from EC2: Lightsail instances never appear in the EC2 API, so they need a Lightsail connection even on an account that already has an EC2 one.
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 Lightsail gave back.
instance snapshot
CreateInstanceSnapshot({ instanceName, instanceSnapshotName })- What it covers
- The whole instance: its system disk and any block storage disks attached to it, as one snapshot, kept in the instance's region of your account.
- How consistent it is, honestly
- The instance keeps running while it is snapshotted, as on every provider here, so the snapshot is crash-consistent: what was on disk at that moment, without a filesystem flush.
And what happens to the old ones
Retention deletes an aged snapshot with DeleteInstanceSnapshot, and that is the whole of it: a Lightsail snapshot is one object, with none of the separate backing snapshots an EC2 AMI leaves behind. Only snapshots VPS Snaps recorded for the job are ever deleted.
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 Lightsail account.
AWS Lightsail 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.
Lightsail is not EC2
Lightsail runs on AWS but has its own API and its own console, and its instances never appear in EC2's. An AWS EC2 connection can't see them and a Lightsail connection can't see EC2 instances, so an account with both needs one connection of each.
Names, not numbers
Lightsail identifies an instance by its name within a region, and a snapshot by its name. VPS Snaps names each one vpssnaps-<instance>-<time> and tags it vpssnaps=backup, so its snapshots are easy to tell from your own in the console.
A snapshot can take a while
The snapshot carries its own state, pending until available, so VPS Snaps checks it every 30 seconds for up to 30 minutes: longer than the other providers' ceiling, because Lightsail copies the whole disk and the larger bundles take the longest.
A replacement from your newest snapshot
With the policy's second block, Recover now creates a new instance from the newest snapshot, or a fresh Ubuntu with the server's databases, files and software restored from its backups, opening the ports the old instance had open. Failover moves traffic by your DNS on Cloudflare: moving a Lightsail static IP isn't offered yet.
FAQs
Can’t find the answer you’re looking for? Reach out to our support team.
How is this different from Lightsail's own automatic snapshots?
Lightsail's automatic snapshots run once a day at a time you set, and keep the most recent seven. VPS Snaps takes snapshots on the job's own schedule, keeps them for as many days as you choose, records every run and alerts you when one fails, and can build a recovery server from the newest. The two can run side by side; neither touches the other's snapshots.
Where are the snapshots, and who pays for them?
In your own AWS account, in the instance's region, as Lightsail instance snapshots, billed by Lightsail as snapshot storage on your AWS bill. VPS Snaps never copies them anywhere, and retention deletes the old ones so the bill stays flat.
Does a snapshot include my Lightsail database or bucket?
No. Lightsail's managed databases and object storage buckets are separate resources that an instance snapshot doesn't cover. For a managed database, point a database backup job at its endpoint and get a portable dump in your own storage 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 Lightsail 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.
Powerful features to give you peace of mind
Rest easy knowing your data and your reputation are safe.
- 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. 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 Lightsail 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.