Using Elastic Load Balancer, it is easy enough to set up SSL at the external load balancer, and serve requests up as http to the applicaion.
When running a single server, it is also possible to configure SSL at the web server (Tomcat) or application (Spring).
When running with the load balancer, is it necessary to pull SSL up to the level of the load balancer? Is there an element of state to the SSL connection that will be lost by forwarding the still-encryped traffic?
I'm afraid that the answer will be "it depends". I had occasion to dig into it a bit when I was working with internet banking security. This was a couple of years ago, though, so it's entirely possible that someone else will come up with something that I forgot or that's changed during those years.
First, it's possible to lose state by doing this - if you have an application running that requires some SSL headers to keep state. If so, you are likely to lose that information (though you may be able to configure your load balancers to forward it in some manner). One example could be if you're using client certificates for authentication.
Second, as Bazze says, it does make your traffic vulnerable to eavesdropping on the local network. How much of a danger this is will of course depend on what your network looks like, and also what kind of traffic it is.
You're reducing the load on your webservers, since they no longer need to spend their resources on decryption and encryption.
When you change your webserver configuration, you can do a simple apache reload without having to enter your SSL key password. This means that you can automate it, enabling continuous deployment and devops and all the buzzwords. (The flip-side to this is that changing your LB configuration may require you to enter the password, but as a rule that's something you don't do as often as fiddling with apache config...)
Troubleshooting your webserver and application just got a whole lot easier, since you can now snoop/tcpdump the incoming traffic directly.
You have fewer places to deal with SSL bugs/security holes. It's usually a lot easier to change SSL settings on one LB than on a large number webservers - especially if those servers are managed by lots of different people from different departments.
Auditing SSL is also a lot easier when there's only one place to audit.
It's a lot easier to keep track of what certificates are in use and when they need to be renewed when they're all in one place. You no longer have the issue of Bob having ordered a cert and put his personal email address in the system for reminders, and then quitting or getting fired so that the reminder bounces and the cert expires and suddenly you have a lot of upset people demanding that it get fixed Right Now! (Not that that has evere happened anyplace I've worked! cough)
Whether it's a good idea to terminate at the LB or not will depends on how you value the various advantages and disadvantages. As a rule, I'd say that unless there is a good reason to do otherwise, you'll want to remove complexity as early as possible - at the network border if that's reasonable from a security and usability standpoint, or as soon thereafter as possible.
I would say that terminating the SSL traffic at the level of the load balancer or the server depends on if you are okay with unencrypted traffic going between the two or not. In most cases the traffic going from the load balancer to the server(s) is traveling inside a private network where you don't really have to care about eavesdropping and man-in-the-middle attacks (as compared to traffic going over the public internet).
Leaving the termination to the ELB also saves you the extra work of terminating the traffic yourself.
Here you can read some more about it: https://security.stackexchange.com/a/30413
Couple of additional thoughts: 1. If you are looking for PCI compliance, you will need to encrypt "data in transit" so you will have to either passthru encrypted traffic to your application, or re-encrypt between the LB and your app server.
