I am also curious about this. My rails app migrated from mysql on RDS to mongodb so I don't need RDS anymore but I cannot figure out how to effectively remove it from my EB environment. Simply deleting the RDS instance attached to my staging environment causes my app to crash failing to connect to the now non-existent database. This seems to be happening in PhusionPassenger configured by EB since my app works fine without an SQL database locally.

also looking for an answer here.

+1. We need to do the same thing

Good question.

Maybe removing the unused database in the RDS console do the trick, but this is just a guess. It's strange that there is no "remove" button in the Beanstalk's console...

There is currently no way to remove RDS from an Elastic Beanstalk configuration. You would need to create a new Elastic Beanstalk application configuration that excludes the RDS configuration, launch your app in this new environment, and then change DNS to point to the new environment.

I'm dumping elastic beanstalk as a platform because of this. There is just no way to change the RDS Endpoint (which is needed when you recover from a RDS snapshot) and recreating the EB environment and changing DNS is just to clunky and error prone.

disappointing

A. This sucks.
B. This puts so many constraints on your future operations on a given environment that you should at least document the consequences and warn people that there is no coming back from setting up an RDS instance for your environment. At least tell them to create a Saved Configuration before doing that!
C. Given these contraints, I would generally recommend not to use the RDS feature of EBS at all. Instead, create your RDS instance and security group separately, then connect via traditional methods (e.g connection URI etc.). It's better for operational flexibility anyway, and you're VERY likely to want to access your RDS instance from outside of EBS.

For those who got bit as we did and are looking for a way out:

1) Simply deleting the RDS instance does not work (you won't be able to run your next environment update), so don't try that.

2) After having set up my RDS instance from EBS (and regretted it), I created a saved configuration, downloaded it from S3 (in your EBS S3 bucket, go to resources/templates/<your-app-name>/), edited it to remove the RDS instance, and re-uploaded it.

3) Loading this modified saved configuration did not work: EBS won't let you modify the RDS settings, so don't try that either.

4) I terminated my environment and re-created it from the above-mentioned saved configuration and the last application version. Then, because the domain name had changed, I also had to update my DNS settings.

Thanks vvvvalvalval for the steps and wow was that painful!

A few extra notes before terminating your old environment (this may yield zero downtime but with stale DB data*):
1. Create a snapshot of your DB.
2. Create a new instance from this snapshot (it will use default security group which has inbound completely open).
3. Modify your saved config to include RDS_ environment variables for your new instance.
4. Upload to s3 as described in previous comment.
5. Go into saved configurations in EBS and "launch environment" from the saved configuration.
6. Once EBS sets up the new EC2 security group, properly configure your new RDS to have a security group that allows inbound from the EC2 security group.
7. Once new environment is up, you should be able to visit the long aws url and test it.
8. If it looks good, "swap environment URLs" (blue-green deployment style) to get your site pointing at your new environment.
9. You now have a new environment using your new non-ebs RDS, so go ahead and terminate the old one which will destroy your previous RDS.
10. Never ever let EBS manage your RDS in production ever again!

* It may be possible to setup an instance that stays in sync with the current instance until you swap the DNS.

Small correction: The default group is not open to everything. It is open to everything also within the default group (Allows all traffic from source {default group}), which cannot not include anything outside your own VPC environment.