Outline
So just what's out there waiting to dig its claws into your AWS operations? Well there are hackers' tools for getting into your system, exploits for taking over and misusing your resources, and methodologies for bringing down your services by force. Let's look at these one at a time.
Access Acquisition
We've already seen at least one hacker attempt to gain unauthorized access to my EC2 Ubuntu instance. As you might have noticed from the maximum authentication attempts exceeded content of those log entries, the hacker tried entering multiple passwords for each login name. That's known as a brute force attack, where hackers rotate through a dictionary of common passwords, hoping that one will turn out to be correct. The reason my system cut those attempts off completely is because the official EC2 Linux images have a default SSH configuration setting - MaxAuthTries - set to six. Even if you did permit password logins for SSH - and even if you did irresponsibly use a weak password - the odds against a hacker getting it right within six tries are pretty slim.
Of course, if a hacker can get hold of real, active credentials, then he won't need to guess. That's why you should be aware of phishing attacks where hackers use social manipulation to get victims to unknowingly reveal their login information. They can similarly take advantage of communications that take place using compromised devices or that are sent over unencrypted connections to sniff your credentials as you use them.
Exploits
Once hackers have gained access to your system, things can only get worse. Whether they do something nasty right away or hang around for months planning something particularly nefarious, if you don't catch them at it, eventually they'll install their malware. That might take the shape of keyboard trackers that record every character you and your colleagues enter in a shell session. It'll only be a matter of time before those trackers capture credentials that'll let them elevate their own permissions.
The malware could also take the form of cryptocurrency mining operations that make heavy - and expensive - use of your system resources so the hackers can profit. Or - and this is the most frightening - they might decide to encrypt key data on your drives and demand large payments before they'll let you decrypt and regain access. This, of course, is known as ransomware, and it's currently the biggest problem facing enterprise-level systems, costing governments and companies billions of dollars each year.
Service Disruption
Even if they don't get into your system, the bad guys can still do a lot of damage from the outside. If, for instance, they detect misconfigurations on your servers - like unnecessarily open network listening ports, poorly written database endpoints, or outdated software like FTP or telnet, they can cause you plenty of problems.
Now's probably a good time to discuss the AWS Shared Responsibility Model. The way the company phrases it, AWS is responsible for the security of the cloud while their customers - that would be you and me - are responsible for the security of whatever you put in the cloud.
Practically, that means you don't need to worry about terrible things happening to the physical servers and storage devices used by your EC2 instances. AWS will protect their warehouses and networking hardware from unauthenticated intrusion and harm. They'll also take responsibility for the software powering any of their managed services - like the API and dashboards you use to configure account activity.
But you're responsible for everything else. That includes the data your instances might generate and the operating systems themselves. So you're on the hook for keeping your operating system and application software patched, and for making appropriate backups of all the data and configuration files you generate.
You're also responsible for making the right AWS-level configuration choices, like getting your security group and network settings right. Depending on the industry and national jurisdiction within which you operate, you might also be expected to meet one or more regulatory compliance standards. AWS provides documentation laying out which standards each service meets. If I expand the Payment Card Industry - PCI - section, for instance, and then search for EC2, I'll see that EC2 infrastructure is, indeed, PCI-compliant.