Outline
An EC2 instance is really nothing more than a regular server. It may not make noise or take up any space in the office but, for the most part, we should treat them just the same. That means whatever you'd do to protect your data center servers, you should plan on doing in EC2. And that means giving serious attention to hardening your operating system.
The very first thing that the phrase "server hardening" should bring to your mind is "software patching". Nothing says "I'm in charge here" like an OS that not only isn't properly patched, but is too old to be patched. Did you know that, over the last 90 days, there were more than 334 million visits to United States government websites from computers running unsupported versions of Windows? I'm talking about Windows 7 and older! Don't be that user!
And don't think no one will notice your unpatched services. Vulnerability scanning tools exist that make it insanely fast and easy to identify exactly what versions of software are running on an application server. Don't think hackers need to break into a sweat scrolling through thousands of lines of data: the scanning software will also helpfully highlight the most critical vulnerabilities for you in fun, primary colors.
Therefore you should regularly update and upgrade all the software you've got running, along with the operating system itself. One way to make that actually happen on your EC2 instances is through the AWS Systems Manager Patch Manager. The integrated automation of the Manager will be especially useful if you've got too many instances to practically perform all the updates manually. Even though there are plenty of orchestration management tools out there that can handle this kind of work - like Ansible - getting it done internally within the AWS ecosystem has its advantages.
Beyond patching, from time to time you should audit your servers to make sure resource permissions are as tight as possible, there are no unauthorized processes running, and no system users have access to resources they shouldn't have. There should also be regular backups on all configurations and data to give you something to fall back on in the wake of a disaster. And by "disaster", of course, I mean a ransomware attack.
Finally, you need to make sure that system event logs are being generated at a level that makes sense for your environment. Of course, such logs won't do you any good if they're not being read. And reading them won't get you too far once you realize how unpleasant it is to regularly read through the millions of lines they spit out. AWS CloudWatch will cover some basic resource usage statistics for your instances - and generate alerts where appropriate - but it doesn't read your actual system logs. So you'll also need to add logfile analytics to your technology stack. The advantage of such analytics is that they do a good job filtering, so they only require we human beings to consume those events that are likely to represent critical system states.
Third party solutions like Datadog, Solarwinds, and New Relic all have AWS integrations. For the right use-case, those options can make the difference between the success and failure of your operations.