The instances in the t2 and the t3 instance family, i.e. the instance types that start with either t2. or t3., are burstable ones. That means the instance collects CPU credits over time that can be used later. If you use less than what you get in the long run – the baseline performance, between 5% and 40% of the available CPUs – you won’t even notice how this system works. But if you use more than that, the instance will either get throttled or you’ll get charged for the excess usage.

When you develop a new serverless function or an API, you should limit the scalability. You don’t need the whole cloud to power a function that you call by hand once every few seconds. On the other hand, scary stories about a runaway Lambda function generated a bill so large it would deter anyone from trying out cloud-scale computing are plenty.

By blocking port 22 on your instance attackers can not brute force it or exploit eventual vulnerabilities. But then how do you access it? With some shell scripting, you can allow access specifically from your IP, thwarting attacks against the SSH server.

When you create Access Keys, you are basically blind how they are used. You can see the effects, like new instances starting or things disappearing, but to see how the key is used you need a separate service. CloudTrail records all calls to the AWS APIs and logs some metadata, such as the caller, the result, and a few others. Using this information you can get an insight into how your keys are used, and whether they have landed in the wrong hands.