Strategy for maintaining Amazon RDS instance on prod vs development

CAVEAT: I don't use Amazon's services, and I don't know how much "extra cost" we're talking about, so this is just general advice...

I guess the real question is "Do you need Dev to be an exact mirror of Production?" - My answer would be "Yes, or at least as close as practical."

The advantage of having Dev and Prod be exact mirrors of each other (infrastructure-wise if not data-wise) is that you can test failover and fault tolerance aspects of your production environment by inducing failures in Dev. This may be worth the cost, at least for a little while to prove to yourself that things will fail over/fail back the way you expect them to.

In my opinion it's worth ongoing cost too, as it lets you do that kind of testing regularly. If you don't regularly test your fault-tolerance and recovery strategy there's a great chance it won't work the day you need it. As a result my suggestion is to spring for the higher cost, and justify it to the executive offices by showing them a plan for fault/recovery testing and sticking to that plan on a regular schedule.

One benefit of Dev and Production being identical which may not translate as well to Amazon/Cloud environments -- You also have the option of pulling the Big Red Handle and moving production operations onto that development infrastructure if a meteor strikes your main datacenter -- My non-cloud world has a VMWare development environment that looks Exactly Like Production. If I ever had to pull that Big Red Handle I'm confident we could keep running (albeit at a reduced capacity) until we could rebuild the production environment.

Use your nightly PROD snapshots, and instigate a micro instance or similar to programatically spin up and spin down the RDS DEV instances in working hours, say between 0700 and 1900. Use the AWS CLI. That will halve your run cost and provide you with access to an almost up to date RDS copy.