Now that we have some breadth of the available services, and some depth about the fundamentals of the key parts. We’re finishing our study off with learning about monitoring, metrics, auditing and logging more generally known as governance.
At a high level we’ll be covering:
- Cloudwatch gathers monitoring and operational data.
- Cloudwatch metrics are the glue for your apps.
- Cloudwatch lets you act on metrics via alerts.
- You can ‘act’ on CloudWatch alerts by notifying, alerting, autoscaling
Sometimes we want to know WHO or WHAT did something, this is when CloudTrail comes in.
Analysis and Diagnostics
X-ray is for distributed services, we can trace through a series of distributed services. Perhaps an API gateway and microservices architecture, like we’ve been looking at to date?
Looking at Serverless too, we have Lambda Insights.
Finally for looking at where we might be failing to carry out best practice, we have Trusted Advisor.
Let’s get started. Table of contents as ever/
I like the explanation of Cloudwatch as a metrics repository in the architecture page.You can input your own custom metrics, as do various other AWS services, e.g. EC2.
And then it’s what you do at the other end that’s up to you. This is really the part you need to get to understand exam question variations.
I have provided a questions sheet for you to think about what might be important, which I’ve taken from the Concepts page. I didn’t need to do any tutorials on CloudWatch to get to grips with the exam, although practice papers helped me find the general point to tighten up, so variations in exam questions didn’t catch me out.
In terms of Cloudwatch Insights, I needed to skim.
- Skim Container Insights to understand about ECS with Cloudwatch.
- Likewise Lambda Insights for Serverless, especially the metrics that can be collected.
- EC2 and on premise have their own ways too – just understand at a high level and contrast which metrics you get as opposed to ECS and Lambda.
Auditing with CloudTrail
Again the exam papers (and infrequency of questions on it) led me to believe if it was one of those things I just needed to know about. I think =of it a bit like a static code analysis tool – run it ad hoc and see where you can tighten things up. Flashcard set shared for your benefit if you want to brush up.
A few questions came up here, so it’s worth being across it. Essentially for microservices, we want to see where the trouble is occuring. With distributed systems it can be cumbersome to isolate the root causes of problems. This is true of problems with both application logic and app performance.
It took me a while to grasp the overview and the idea of sampling. For that reason, I’d advise you to take a look at my question sheet in this one, as I got questions wrong a few times across my practice runs. Definitely understand the ides of the X-Ray Daemon as I got several troubleshooting questions around that.
Bit of a quicker week this week, because you’ve already covered so much. You’ll also need time to review your original study plan, and schedule extra time for your spaced repetition – you won’t have google come exam time after all. When you’ve got your flashcards of concepts and your periodic reminders to test yourself, you’re ready to take practice papers .. if you haven’t already!
I hope you found this study plan useful, I’ve tried to get you thinking in terms of cloud concepts and critical thinking patterns. This way, the breadth of required exam knowledge doesn’t throw you. With these in place, you should be able to eliminate many options straight away.
Absolute worst case, you can still make educated guess about the questions you don’t know. I’m hoping they will be few and far between of course. Thanks for following along, and I’d really appreciate your feedback as it helps me provide good future content.