The current infrastructure contains two servers located in Amazon EC2: application server, and MySQL server.

Concern: security of communication between the application server and the database, without degrading performance.

Current setup: MySQL server has an elastic IP, which the application uses to connect to the server. The reason is that the internal IP changes on reboot, while elastic remains constant. The connection on MySQL is firewalled to the application server, and MySQL itself has the user assigned to the application server's IP.

Ideally we want for the two servers to communicate using the internal IPs. We would prefer not to implement communication over SSL, for performance reasons.


  1. Am I correct in that a man-in-the-middle attack is possible, because the communication happens over network that uses the elastic IPs?

  2. How much of a performance hit would implementing SSL communication between the two servers can we expect?

  3. Is there an alternative, apart from custom scripting, to dealing with the changes in the internal IP?

  4. Without SSL, can a man-in-the-middle attack still occur over the internal network, from an EC2 neighbor?

  • 3
    #1 Use a VPC -- Private IP Addresses are static in VPCs. #3 Use a VPC. #4 Don't allow communication between these instances except from their own security group(s). Aug 6, 2014 at 14:53
  • @HyperAnthony What's #2? I MUST KNOW!
    – ceejayoz
    Aug 6, 2014 at 15:33
  • @ceejayoz #2 must be, "Yes, use SSL. No, there's not a significant impact for connections that stay open." Aug 6, 2014 at 17:58
  • @NaftuliTzviKay I suspect you're right.
    – ceejayoz
    Aug 6, 2014 at 17:59

2 Answers 2


Using a VPC will solve a lot of your problems, as private IP addresses will be static there. Amazon is strongly encouraging people to move to VPC for reasons like this. Once you have one, your two systems should be able to talk over the AWS-internal network.

To answer your question about exposure along the aws-public <---> aws-public route, it is theoretically exposed. However, it's all likely taking place over Amazon's internal switch-fabric so the exposure to bad-actors is likely the same as it would be for internal-only traffic routing.


As recommended in sysadmin1138's answer, these kind of situations are why VPCs were added to Amazon Web Services: so you can have a private intranet between EC2 instances. In my opinion, that's part one of the solution: put your database server in a VPC with your application server and only allow access to the database server from the internal (not-internet-facing) network and reject access to TCP 3306 from the external (internet-facing) network.

The second step is "yes you should be using SSL and no, the performance costs are not very significant." You can certainly test connections to your database over SSL versus plaintext, but the overhead is going to be relatively minor at best. Your actual performance cost will vary based on usage.

Does your application:

  1. Create new database connections for every single SQL operation?
    • If so, you'll have more of a performance cost, though still a relatively minor one.
  2. Cache/pool a number of database connections and reuse them as needed?
    • If so, there's almost no reason not to use SSL.

Personally, if I have the option to use SSL, I use SSL. Using 2048-bit RSA keys vs 4096-bit RSA keys may speed up initial handshake time, as well as trimming your cipher list to speed up time to first byte; you'll have to inspect what your options are for MySQL.

On a security note, use ciphers with PFS and don't use SSLv3; use only TLSv1.2 if you can (ie: if you're running any MySQL/SSL version later than 2008). I'm not sure how much MySQL lets you customize this.

TL;DR: Only expose your MySQL port over the VPC internal network to your application server, definitely use SSL, but benchmark it if you're concerned about speed and if you're not reusing connections.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .