When customers migrate application databases to Amazon Relational Database Service (RDS) SQL Server, they typically want to restore multiple copies of those database to segregate separate access domains such as production, quality assurance, testing, development, etc. Although the standard AWS recommendation is to use independent RDS instances, this can be an expensive and undesirable proposition. If you try to restore a backup file to a DB instance multiple times, you hit the following issue and troubleshooting roadblock:


Database <database_name> cannot be restored because there is already an existing database with the same family_guid on the instance


You also can’t restore the same backup file to a DB instance multiple times. That is, you can’t restore a backup file to a DB instance that already contains the database that you are restoring. Instead, restore the backup file to a new DB instance (Translation: spend more $$$).

Fear not, here is one possible workaround. Using an on-premise SQL Server instance (or a SQL Server instance running on EC2), a SQL database can be exported into a BACPAC file and then imported back into that same SQL instance from that BACPAC file, thus creating “legal” copies of the same database that can now be restored into a single AWS RDS instance. For reference, a BACPAC file is a Windows file with a “.bacpac” extension that encapsulates a database’s schema and data, whose primary use case is to move a database from one server to another. These files are a variant of data-tier applications (DAC), in the family of DAC packages (DACPACs). All DAC operations are supported starting with Microsoft SQL Server 2008 R2. Note that there are some exceptions, so be sure to review DAC Support for SQL Server Objects & Versions. For more information on Data-tier Applications refer to DAC concepts.

Need help implementing? Contact Cloudnexa today.

Tutorial: Restoring Multiple Copies of a Database on AWS RDS SQL Server

In this tutorial, we are going to duplicate the “AdventureWorks2016” sample database using SQL Server 2016. Open SQL Server Management Studio, select the database, select “Tasks”, and select “Export Data-tier Application…”.

  • Click Next

  • Select the “Save to local disk” radial button, choose a path and name for your “.bacpac” file. Click “Next”.

  • Review the summary. Click “Finish”.

  • Review the results, everything should read as a “Success”.

  • Back in SQL Server Management Studio, right click on “Databases”, “Import Data-tier Application…”.

  • Specify the BACPAC file to import. Click “Next”.

  • Specify settings for the new copy of the database.

  • Review the summary and verify the specified settings. Click “Finish”.

  • Review the results, everything should read as a “Success”. Create full backups of the two databases and upload the “.bak” files to S3 (this post assumes you are familiar with, and have set up the prerequisites for AWS RDS SQL Server Native Backup and Restore).

  • Connect to the target SQL Server RDS instance and restore the first database backup. To restore your database, you call the rds_restore_database stored procedure. The following parameters are required:

    @restore_db_name – The name of the database to restore.

    @s3_arn_to_restore_from – The Amazon S3 bucket that contains the backup file, and the name of the file.

    • Sample TSQL:
      exec msdb.dbo.rds_restore_database
      exec msdb.dbo.rds_task_status @db_name='database_name' 


    • Actual TSQL statement to restore our first database backup:
      exec msdb.dbo.rds_restore_database


    • Actual TSQL statement to monitor the restore of our first database backup:
      exec msdb.dbo.rds_task_status @db_name='AdventureWorks2016'

  • Once the “lifecycle” column reads “SUCCESS”, you can start the restore of the second database backup.
    • Actual TSQL statement to restore our second database backup:
      exec msdb.dbo.rds_restore_database


    • Actual TSQL statement to monitor the restore of our second database backup:
      exec msdb.dbo.rds_task_status @db_name='AdventureWorks2016Copy1'

  • Watch for the “lifecycle” column to read “SUCCESS”. Congratulations, you’ve restored multiple database copies to the same, single RDS instance.

Need help implementing? Contact Cloudnexa today.

An AWS launch configuration is a template that an Auto Scaling group uses to launch EC2 instances. This template requires configurations such as the ID of the Amazon Machine Image (AMI), the instance type, a security groups, and key pair. A launch configuration is then required to create an Auto Scaling group. Below we will discuss configurations against resources that no longer exist making the launch configurations invalid.

To get started login to your vNOC Account, or contact Cloudnexa to get started with using Account Review today!

About the Account Review Check

Amazon Machine Image (AMI), Security Group, or Key Pair can be removed over time making the launch configuration invalid. An AWS Issued AMI over time is updated with new AMI’s that include the latest patches and functionality. These newly updated ones are favored over previous editions and will eventually be removed from public visibility making your launch configurations invalid. The same scenario can happen with custom created AMI’s. Since a launch configuration cannot be updated once created with a new AMI, Security Group, or Key Pair, the launch configuration should be cleaned up to avoid being inadvertently used, and minimize the overall clutter in the AWS Account.


  1. Login to the AWS Console and navigate to the EC2 Service -> Launch Configuration (Auto Scaling Section),
  2. Find the affected launch configuration, select Action, and Delete it.

Today we will focus on Amazon RDS and its ability to create manual, and automated backups of your database instance. When you create a DB snapshot on your Amazon RDS database, a backup of the entire DB instance is created (not just individual databases) and stored into a snapshot volume.

Automated backups are created during the backup window configured on your DB instance. These automated backups are created during the period specified, and automatically cleaned up according to the retention period configured (currently with a max of 35 days). With managed cleanup by AWS for automated backups, no further attention is required.

RDS database instances can also be manually backed up into manual snapshots. Manual snapshots are necessary to persist backups beyond 35 days and after an RDS database is deleted. If an RDS instance is terminated, then all automated snapshots are removed at the same time by AWS. These manual snapshots are critical to a customer’s backup retention policy beyond 35 days, or the life of the RDS instance. Cloudnexa can provide both governance policies to manage retention on these manual snapshots, as well as provide an Account Review check to quickly identify outliers based on the age of the manual snapshots. Below we will discuss our Account Review check.

About the Account Review Check

Cloudnexa’s vNOC Account Review will check for any manual snapshots that exceed a certain age threshold, to keep track of lingering snapshots that might no longer be in use, or necessary to keep. Cleaning up any unnecessary manual snapshots of an RDS database instance can be a cost savings. We have seen customers save hundreds of dollars by removing long forgotten RDS manual backups. At the time of writing this the charge for excess snapshot storage is $0.095 cents per gig in us-east-1 for a MySQL RDS Database.

The flagged states for this check are all time based, with red being the oldest at 365 days since the snapshot was created.


  1. Login to the AWS Console and navigate to the RDS Service -> Snapshots.
  2. Select the filter for Manual Snapshots.

  3. Select the snapshot to be deleted, then select Snapshot Actions and click delete.

AWS Best Practice adherence helps us, and our customers achieve successful, cost effective deployments on AWS. Even if you are not an MSP, our vNOC Account Review will help you manage like a pro.

Cloudnexa is happy to announce we have launched our 115th new Account Review check into our vNOC Management Platform. The vNOC Account Review utility provides Cloudnexa staff and our customers an automated validation of AWS account best practices at scale. Ensuring your environment is continuously monitored for things like: security, cost, audits, and usage. Checks are broken down into these categories, and individual AWS Services for better grouping, visibility and organization. Our Account Review platform is extensible, which allows us to add on new validation checks quickly. If you have some recommendations, or want to know more, reach out to us today.

To use Automated Account Review simply login to vNOC, and select Account Review under the Monitoring section. Leveraging these account checks helps you quickly and visually manage all your AWS accounts from a single interface. For our vNOC Free Tier customers, update your vNOC account today to gain access to these features by simply allowing Cloudnexa to be your AWS reseller, or engaging Cloudnexa as your MSP.