When a large scale attack reaches your machines, there's a limited amount of things that the code can do to mitigate the problem.
For low volume attacks, you could attempt to recognize bogus requests early and rate-limit/ignore sources that do not appear to do anything useful to lessen the amount of computational resources your application wastes on them. You can limit unauthorized connection attempts rather heavily, and move all your static unauthorized assets like images and CSS onto a content delivery network.
For high volume attacks, most of the traffic will not reach your application and is probably not even intended for your application. The purpose there is to completely saturate the network connection to your machine, or to spend all CPU time and memory in the kernel on buffering.
The way to combat the latter kind is to work with your hosting provider and their upstream providers to prevent traffic recognized to be part of an attack from reaching the site in the first place. This is an ongoing process and nothing you can solve up-front, except by establishing communication paths and terms of service.
You can also gain some resilience by making your service distributed and placing all core services on backend machines separate from the frontends. This ensures that if your some of your fluffy cloud frontends get hammered, a few of them will remain reasonably functional and be able to talk with the backends as normal.