Issue 1:
Elastic IP addresses should not be used to preserve the address of a "back-end" server. There are 2 reasons:
- Usually, you do not want back-end servers to be exposed to the internet and Elastic IP addresses only work from the internet into your EC2 instance.
- If you connect from one EC2 instance to another EC2 instance by it's Elastic IP address, then the connection leaves your VPC and re-enters the VPC. This makes security harder and will incur data traffic charges.
Instead, you should reference your back-end server by it's private IP address. Stopping and restarting an EC2 instance will not change the private IP address. Only when an EC2 instance is terminated will the internal IP address be released. And when you launch an EC2 instance, you can optionally choose it's private IP address.
You can create a DNS entry (Route 53 private hosted zones) for your back-end server.
Another thing you can do, but it's not required, is to create a network interface with your private IP address. Then attach that network interface to the EC2 instance. If you need a new back-end server, then just move the network interface to the new instance and the private IP address will move with it.
Issue 2:
RDS instance endpoints do not change over time.
Also, RDS instances cannot be stopped. They can only be deleted. But, even if you delete an RDS instance and re-create it, if it has the same RDS instance ID, then it's endpoint will remain consistent.
So it's safe, and best-practice, to reference your RDS instance by it's hostname myapp-production.cg4mxcg62ca0.us-west-2.rds.amazonaws.com
.
Final Thoughts:
Put your Redis server and your RDS instance in private subnets in your VPC. There is no reason why the public needs access to them. Your Rails app instance should be in a public subnet because the public will access your app through that instance.