There are two general strategies for dealing with traffic surges: increasing capacity and reducing cost.
Increasing capacity means auto-scaling, which everyone was very excited about when public clouds first became available. In its most basic sense, this will boot up more webservers for you based on load and add them to a load balancer, but since can be a pain to manage, there are more automagic solutions as well, like Elastic Beanstalk.
The trouble with automated capacity expansion is that its also automated bill expansion - 10x normal traffic means 10x servers means 10x money you have to pay. That's why, while it's a useful strategy to keep in mind, I think you should always start by seeing how much you can cheat.
By cheat, I mean cache, which rests on the idea that most of the time you can give users slightly out of date data and they won't notice, and that can save you tremendous amounts of time. Imagine that you have a page that you decide it's ok if it's five seconds out of date, and it gets 20 req/s. Without caching, you're running that calculation 1200 times a minute, whereas with caching it's only 12. You can see how this can make a tremendous difference.
There are of course many types of caching, and a successful website will use several of them. But for your use case, there are two pretty good and easy options.
The first is to make the site completely static. This assumes that you can do so, but if you can, then you just have Nginx serve up the html directly, and it can serve tons of requests with no sweat.
If you need some level of dynamicity, then doing some full-page caching is a good option. Nginx has some capability to do this, but I really like Varnish because of its flexibility.
Whatever option or options you go with, make sure you do load testing to validate that you've set it up properly; sometimes fixing one spot exposes a new bottleneck.
