Are you right-sized or overprovisioned on your Microsoft licensing? Not sure? By completing an Optimization and Licensing Assessment (OLA) with Cloudnexa, we can help you evaluate your Microsoft workloads’ licensing, identify opportunities for consolidation, and ensure license compliance. An OLA is an important component of Migration Readiness Assessments.

Why should you consider doing an OLA with Cloudnexa?

Cost Savings

An OLA will empower your cloud strategy and help you discover cost-effective and flexible licensing options. Without optimizing your cloud infrastructure, the cost of overprovisioning third-party licensing can exceed the cost of compute. Leverage the recommendations from Cloudnexa’s OLA to get the most value from your existing licensing entitlements by configuring your instances to require fewer licenses while still maintaining highly performant applications. Adapt your on-premises licensing strategy to enable your cloud migration.

Cloudnexa starts with your vendor licensing position and specific use rights and aligns sizing. We are experts in vendor licensing, use rights, contracts, AWS sizing, and how to help customers maximize cost and optimization. Cloudnexa will assist in creating a strong modernization strategy to exit from vendor workloads requiring expensive licensing and long-term commitments.

An OLA will help you discover cost-effective and flexible licensing options.

Also consider migrating to an AWS service like Babelfish for Aurora PostgreSQL to run Microsoft SQL Server applications on PostgreSQL with little to no code change.

Explore Flexible Licensing Options

Use the results of a Cloudnexa OLA to avoid unnecessary licensing costs and vendor lock-in. Model different licensing scenarios with license-included or Bring Your Own License (BYOL) instances, to meet the needs of your business. Flexible licensing options enable you to drive seasonal workloads and support agile experimentation, as well as to model dedicated environments, so you only pay for what you need.

Accelerated Microsoft Workload Migration

Completing an OLA also helps prepare you to migrate to AWS. AWS supports all of your Microsoft workload needs. Cloudnexa’s evaluations can help you determine whether you should develop a Bring Your Own License (BYOL) model or leverage an AWS-provided license strategy as the best approach. Cloudnexa will help you develop a plan and a migration strategy which will accelerate your AWS Microsoft workload migration process and ensure key areas of concern are addressed.

An OLA helps you prepare to migrate to AWS.

Leveraging this funded program (subject to qualification) helps you accurately evaluate the existing Microsoft workloads in your on-premises and/or cloud environment, and then provides recommendations—based on current resource utilization data—on the deployment options for Microsoft workloads on Amazon Elastic Compute Cloud (Amazon EC2) across different deployment options. This process will also highlight the appropriate options available such as BYOL with Dedicated Hosts or shared tenancy Amazon EC2.

Right-size your Resources

Discover workloads in your on-premises or cloud environment and build an inventory of your compute resources. Our tooling-based approach will help you determine your actual utilization requirements to help optimally select the lowest-cost AWS EC2 and RDS instance size and type for each workload. Use this data to determine the right blend of on-demand and spot instances, dedicated hosts, savings plan, and other options tailored to your environment.

Want to learn more or get started? Contact us.

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.

In many of our migration and application refactoring projects involving Microsoft workloads, one of the most common areas of customer confusion is whether or not to use the Amazon SQL Server Relational Database Service (RDS). Amazon RDS for SQL Server is a relational database management system provided as-a-service, which makes it easy to set up, operate, and scale SQL Server deployments. However, only the SQL instance service endpoint is exposed and you will not gain access to the underlying infrastructure (server or operating system level). In short, this is not the same as running SQL Server on a virtual machine or physical hardware, and there are many caveats and limitations to consider. As a general rule, if you are running a proprietary application that relies on SQL Server databases (SharePoint, Dynamics GP, RMS, etc.), it is not likely to be compatible with Amazon RDS. We recommend that you consult with the application vendor to determine if their SQL databases are compatible with Amazon SQL Server RDS prior to making any architectural commitments.

As of this writing, Amazon RDS for SQL Server currently supports Microsoft SQL Server 2008 R2, 2012, 2014, and 2016. Information about the supported minor versions is available in the Amazon RDS User Guide. Below are some general limits for all Amazon RDS for Microsoft SQL Server editions:

  • You can only create a maximum of 30 databases on your RDS DB instance.
  • The minimum allowable storage size for a SQL Server DB instance is 20 GB for the Express and Web Editions, and 200 GB for the Standard and Enterprise Editions.
  • The maximum allocable storage size is 4 TB for the Enterprise, Standard, and Web editions, and 300 GB for the Express edition.
  • Amazon RDS doesn’t support some SQL Server components including SQL Server Analysis Services, SQL Server Integration Services, SQL Server Reporting Services, Data Quality Services, and Master Data Services. To use these features, you would need to run SQL Server components on a virtual machine (such as an Amazon EC2 instance with Amazon EBS storage, pursuant to Microsoft licensing policies).
  • Amazon RDS doesn’t currently support increasing storage on a SQL Server DB instance. We recommend that you provision storage according to anticipated future storage growth (Note that there are ways around this limitation, but it requires downtime).
  • In terms of Microsoft SQL Server security, the following server-level roles are not available: bulkadmin, dbcreator, diskadmin, securityadmin, serveradmin, sysadmin. The following server-level permissions are not available: ADMINISTER BULK OPERATIONS, ALTER ANY CREDENTIAL, ALTER ANY EVENT NOTIFICATION, ALTER ANY EVENT SESSION, ALTER ANY SERVER AUDIT, ALTER RESOURCES, ALTER SETTINGS, AUTHENTICATE SERVER, CONTROL_SERVER, CREATE DDL EVENT NOTIFICATION, CREATE ENDPOINT, CREATE TRACE EVENT NOTIFICATION, EXTERNAL ACCESS ASSEMBLY, SHUTDOWN, UNSAFE ASSEMBLY, ALTER ANY AVAILABILITY GROUP (SQL Server 2012 only), CREATE ANY AVAILABILITY GROUP (SQL Server 2012 only). For the full list, refer to this link.
  • Amazon RDS for SQL Server does not support importing data into the msdb database.
  • You can’t rename databases on a DB instance in a SQL Server Multi-AZ with Mirroring deployment (Note that there are ways around this limitation, but some downtime is required).
  • Some ports are reserved for Amazon RDS use and you can’t use them when you create a DB instance.
  • In terms of local time zones, this can only be set during instance creation. You can’t modify the time zone of an existing SQL Server DB instance. You also can’t restore a snapshot from a DB instance in one time zone to a DB instance in a different time zone.

For the full list of published general limits, refer to this link.

In addition, not all Microsoft SQL Server features are available in AWS RDS. For example – database mail, maintenance plans, and FILESTREAM are not supported. We encourage you to thoroughly review the available features for your chosen version of SQL Server to determine compatibility. The full list of supported versions and features can be found here: Version and Feature Support on Amazon RDS.

What does the date July 14, 2015 mean to you?

Are you having trouble thinking of anything? Don’t panic. You did not forget your Great Aunt Ethel’s birthday, or your 9-and-three-quarter-year anniversary (but take this as a reminder to mark your calendar for those things).

So what does that date mean, then? Drumroll, please: It was the official end of life date of one of our all time favorites, the Windows 2003 operating system.

In other words, on July 14, 2015 Microsoft deemed Windows Server 2003 obsolete and will no longer issue critical updates for the platform. This was 13 years ago, and given the fast-paced nature of the world that we know as modern technology, that amount of time is long enough to make it an archaic artifact, we heard a rumor Windows Server 2003 is actually in the running to be named the Eighth Wonder of the World 😉 The problem for many companies is that… it is not exactly obsolete, or ancient history, yet. They still use 2k3 (or, they did until recently). But now they will have to transition. If you are a part of that demographic, then congratulations, you stuck it out. You made it to the end. You know how to commit, and that is truly commendable.

But you still need to turn elsewhere now, if you have not already. We can help you do that. Get in touch with Cloudnexa today and we can work together on an game plan to update from 2k3. In the meantime, here are some details about Windows Server 2003 end of support.

What does end of life, or end of support mean?

It is the end of 2k3’s lifecycle. If you’re operating on that platform, it will still work, but without any further critical updates. The most threatening issue will be security. Without further security updates, your PCs will be exposed to cyber security threats, and could result in malicious attacks and lost or stolen data. Compatibility will pose another issue. As the software and hardware you use is updated, it will likely no longer be compatible with Windows 2003.

What’s Replacing Windows 2003 Server?

The cloud is, largely. According to a recent survey by technology market research firm Vanson Bourne, approximately 75% of companies using 2k3 shifted their servers over to the cloud when Windows ended support. We recommend doing the same and we will assist you with the transition. For one, it’s your most cost-effective option. You only pay for what you use in the cloud, as opposed to the on premise model, where you will pay for a fixed amount of storage space (a significant portion of which you will likely never use). The transition is also easy, thanks to companies like us that make switching as seamless as possible.

In conclusion

It’s been seven months since the Windows Server 2003 end of life announcement, and if you haven’t made the transition yet, the urgency for you to do so is increasing exponentially every day. It may seem overwhelming, but this is not something to put off. As you continue to put it off, you are only putting yourself more and more at risk of security breaches, and inability to update necessary hardware and software. Get in touch with us if you need to transition and we will be glad to help!