1. For PROD environments, use Multi-AZ deployment (mirroring) and provisioned IOPS. It is much harder to change this after the fact – if you want to ‘upsize’ your RDS instance.
2. Recreating a prod environment from a dev or staging environment (Create a backup, restore a database from backup – Read this post )
3. Pushing large amounts of data into an RDS instance – using SQL Bulk Copy (bcp) – read this post.

Backup and Restore in RDS

Restoring from a backup essentially involves dropping your existing RDS instance and creating a new one. This has implications. The endpoint address associated with your original RDS instance is lost in this process – and you will need to remap (anything using that instance) to the new URL.

What can you NOT do with RDS?

• You can’t copy, paste or create files in the underlying disk system. If your on-site DB server has non-SQL related files on disk, they can’t be ported across.
• You can’t run batch files, Windows Command Shell files or PowerShell scripts in the host.
• You can’t directly monitor disk space, CPU usage or memory usage from the host. AWS provides a different way for monitoring.
• You can’t copy backup files into the local disk from another location and restore databases from there.
• You can’t decide which drive your database files go to, AWS has a default location for that.

The post Amazon RDS for SQL Server–Notes from the field… appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.