Custom domain name for AWS RDS

First, note that you may be looking at the incorrect operation -- you describe that you want to change storage size, but have quoted documentation describing storage type. This is an important distinction: RDS advises that you won't experience an outage for changing storage size, but that you will experience an outage for changing storage type.

Expect degraded performance for changing storage size, the duration and impact of which will depend on several factors:

• Your RDS instance type
• Configuration
• Will this occur during maintenance?
• Will these changes occur first on your Multi-AZ slave, and then failover?
• Current database size
• Candidate database size
• AWS capacity to handle this request at your requested time of day, at your requested availability zone, in your requested region
• Engine type (for Amazon Aurora users, storage additions are managed by RDS as-needed in 10 GB increments, so this discussion is moot)

With this in mind, you would be better served by testing this yourself, in your environment, and on your terms. Try experimenting with the following:

• Restoring a new RDS instance from a snapshot of your existing instance, and performing this operation on the new clone.
• With this clone:
  • Increase the size at different times of day, when you would expect a different load on AWS.
  • Increase to different sizes.
  • Try it with multi-AZ. See if your real downtime changes as compared to not enabling multi-AZ.
  • Try it during a maintenance window, and compare it with applying the change immediately.

This will cost a bit more (it doesn't have to... you could do most of that in 1-3 instance-hours), but you will get a much cleaner answer than peddling for our experiences in a myriad of different RDS environments.

If you're still looking for a "ballpark" answer, I would advise to plan for at least performance degradation in the scope of minutes, not seconds -- again dependent very much on your environment and configuration.

For reference, I most recently applied this exact operation to add 10GB to a 40GB db.m1.small type instance on a Saturday afternoon (in EST). The instance remained in a "modifying" state for approximately 17 minutes. Note that the modifying state does not describe real downtime, but rather the duration that the operation is being applied. You won't be able to apply additional changes to the actual instance (although you can still access the DB itself) and this is also the duration that you can expect any performance degradation to occur.

Note : If you're only planning on changing the storage size an outage is unexpected, but note that it can occur if this change is made in conjunction with other operations like changing the instance identifier/class, or storage type.

Is this a security risk?

Theoretically, yes. In practicality, there's almost certainly no significant risk, but anything allowed that isn't needed is arguably a "risk."

What should be the ideal outbound security rule?

Nothing should be allowed, because your database doesn't need to initiate connections. Explanation follows.

In my perspective, the outbound traffic for the RDS security group should be limited to port 5432 to our EC2 instances, is this right?

Almost correct, but technically incorrect (or ambiguously stated).

The instances aren't using port 5432 on their side. That's the destination port. The source port on the instance side typically changes with each connection.

Security groups are stateful and their rules are only needed to allow the initiation of connections. Response traffic is automatically allowed, without configuration.

“Security groups are stateful — responses to allowed inbound traffic are allowed to flow outbound regardless of outbound rules, and vice versa.”

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html#VPCSecurityGroups

Inbound connections to the database have a destination port of 5432. The single inbound rule thus allows these connections to be established and the reply traffic to be returned.

The outbound "allow" rule in the database security group is not actually doing anything now.

The database doesn't initiate connections, so nothing outbound should need to be allowed. This even remains true even in the case of replication within RDS. The RDS machines clearly must connect to each other in such a configuration, but it turns out they have their own "hidden" network across which they can establish these connections, and it does not depend on your security group settings.