AWS provides a complete monitoring engine called CloudWatch. This works with metrics, including custom, user-provided metrics and it’s able to raise alarms when any such metric crosses a certain threshold. This is the only tool used for perfomance monitoring tasks within AWS.
This text will cover a monitoring scenario regarding deploying an arbitrary application to the “Cloud” and then being able to determine what causes performance limiting, be it in the application code itself or coming from limits enforced by Amazon.
Scenario
Let’s assume that you have just started using Amazon Web Services and are deploying applications on this free tier or by using general purpose (T2) instances. You quickly learn that the general purpose instances work with “credits” that allow dealing with short load spikes through performance bursting, but when these credits are exhausted, instance performance is reverted to some baseline. These particular details do not make a lot of sense, but you need to know if the application can meet the desired service targets while sticking to this setup.
When do you need to use some form of Cloud Distribution?
If you consider this concept a form of caching, then you need it when your website passes a certain threshold in terms of users and the volume of data that is being sent out. The actual numeric figure depends entirely on your setup – you may have large files and sending them out of your server may fill up the available bandwidth. Or you may have a lot of users and may want to ease the load on the server by pushing some of this load to somewhere else.
Nevertheless, the purpose of this article is to show you how this is being done by using the AWS CloudFront.
AWS CloudFront
First, you need to go to the “CloudFront” option in the AWS Console and attempt to create a Web distribution. On the creation page you should first fill in your domain name as the distribution origin (the primary source of the content):
Starting from today I am one of the AWS CSA(A) certified professionals. The license number is generated sequentially so it is easy to infer that I am the the 16.891st person on this planet holding the title, but given the 2 year recertification cycle I assume that many of those who were certified before may have not renewed their certification status.
Starting on the path
I have registered my own private AWS account in the second part of 2014, around the time when I was assigned to the project I have talked about in the previous text. I did not make much of that account and still do not use it for more than cloud backups; without a professional motivator, getting on this path will not truly bring anyone very far.
The game changer was the DevOps work I have started doing for a customer of my employer at the time: they had a fully configured AWS environment I was given access to. The year Amazon suggests you to spend in a professional environment before trying to get certified is by no means a spurious requirement; there is an entire ecosystem that needs to be mastered in order to make the best use of it.
Preparation
The certification adventure started about a month ago by reading this Reddit post. I didn’t get the free full month of study on offer due to the timezone difference but the seed got planted. What happened next?