Currently, AWS has three associate level certifications: Solutions Architect, Developer and SysOps Administrator. In 2017, I have passed the certification exams for the first two certifications and as I visited AWS re:Invent in Las Vegas last year, I decided that I would like to also pass the one that is missing from my curriculum right now.
On Course For Certification
One of the ways to prepare for the AWS Associate certifications (apart from reading the documentation), is completing one of the many courses being offered on the on-line learning platforms. For my first two certifications, I used the certification training offered by A Cloud Guru which were very good. However, in the meantime I have also completed some trainings on the Udemy Platform by Stephane Maarek on miscellaneous topics related to Amazon Web Services (CloudFormation Masterclass, AWS Lambda and the Serverless Framework) that I also like very much, so I decided to start my certification course with Stephane’s wonderful “Ultimate AWS Certified SysOps Administrator Associate 2019” (quite a mouthful, but it’s a 17 hour journey).
The Same Old Song?
Some of the topics for this certification come up in other tracks as well, e.g. “How do you obtain information instance information from the EC2 instance currently running?” and topics like “Is available memory a standard EC2 Metric?”.
The answer to the last question used to be that EC2-instance memory statistics are not available as CloudWatch metrics out of the box, however AWS does provide some PERL scripts to capture this information as Custom CloudWatch metrics. Although AWS now provides a brand new CloudWatch Agent that can be installed on both EC2 and on-premise environments, there is still value in creating your own custom metrics for CloudWatch, as the CloudWatch agent might not expose the metrics you’re interested in for your environment or use case.
For the older generation of developers and system administrators, PERL might have been a valid choice. However, as a developer I am much more comfortable with a well-structured and readable language like Python, so I was wondering how complex it would be to create my own custom metrics using some Python scripting.
Preparing the environment
One of the (may) good features on AWS is its fine-grained security model; you can easily tailor the permissions required for your specific use case and allow the service or program no more privileges than it requires to complete its task.
IAM – roles and policies
First, we start by defining a new role to be used for the EC2 instance. This will allow the EC2 instance to send its data to CloudWatch:
In this role, we include a new policy that only allows it to send metric data to CloudWatch:
Finally, we attach this IAM policy to the EC2 instance we’re launching:
Now launch your EC2 instance, I am launching mine in the eu-west-1 (Ireland) region.
Create an IAM user
As I am planning to send the custom metric data using the AWS Boto3 library, I will need to create an IAM user as well for programmatic access only; I’ve assigned this user the same policy (e.g. send data to CloudWatch) and copied its secret and access keys from the IAM console.
As I have launched my instance using a rather bare Amazon Linux 2 AMI, I do not yet have all the required packages installed. Let’s assume that we will be using this EC2 instance for serving some webserver traffic and it will be running a simple installation of Apache’s httpd.
To install the dependencies, SSH into your EC2 instance after launching has completed: