title: RDS managed via CloudFormation, will Multi-AZ prevent Replacement update behaviour?
body: <p>So we've got an RDS instance in prod and are looking to change the <a href="http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-rds-database-instance.html#cfn-rds-dbinstance-dbinstanceidentifier" rel="nofollow noreferrer"><code>DBInstanceIdentifier</code> parameter</a> (well remove it actually, it got added turns out thats not great for what we need to do moving forward). This requires a <a href="http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement" rel="nofollow noreferrer">Replacement</a> update behaviour, from <a href="http://blog.jasonantman.com/2014/12/aws-cloudformation-and-rds-snapshots/" rel="nofollow noreferrer">my reading</a> it seems like if we performed a stack update this would kill the data on that instance and rebuild it even if we set <code>DeletionPolicy: Snapshot</code> on the resource (because that only applies on whole stack deletes, not resource replacement operations).</p>
  
  <p>Now what we're trying to achieve is to remove the identifier with as little downtime as possible and obviously without losing the data. Seems like what we need to do is:</p>
  
  <ol>
  <li>Stop the services using the DB.</li>
  <li>Manually trigger a snapshot.</li>
  <li>Remove the <code>DBInstanceIdentifier</code> parameter and set <code>DBSnapshotIdentifier</code> parameter to restore from that one on the replacement.</li>
  <li>Swap over all the configs to look at the new DB URLs.</li>
  <li>Turn back on all the services like nothing happened!</li>
  </ol>
  
  <p>If I turn on Multi-AZ first will this result in no downtime (and not having to the snapshot stuff)? ie. the "Update requirements replacement" is handled transparently by RDS.</p>
  
  <p>If not, does anyone see any flaws in my logic or have any advice in this scenario?</p>
  
  <p>Cheers,
  Alex</p>
  
  <p>-- The instance is a postgresql 9.6 node if that makes a difference, we're not using Aurora which seems like it might be a little simpler!</p>
  
  <p>PS. Bonus points if you have any reading material for how to set up <code>prod</code> -> <code>stage</code> env replication in RDS, that's my next task after this :)</p>