by Brandon Knitter | Technical Consultant at Taos Amazon’s most recent outage has garnered a lot of buzz in the industry. Google for “amazon outage 2017” and you’ll find results that range from acknowledgement to outrage. My opinion will fall somewhere in between. Let’s be honest, shit happens and infrastructure fails (both hardware and software). […]
The Amazon AWS service API is an essential tool for automating the deployment, monitoring, and management of AWS resources. To grant programs the necessary API access, a common technique is to create AWS access keys and store them in configuration files, or even hardcoded into source code. I employed this method in last month’s installment, Implementing A Custom AWS Dashboard.
However, using keys in this way adds a security risk. Keys stored in configuration files or source code are at risk for unauthorized disclosure, and these keys grant unrestricted access to all your account’s AWS functions, far broader access than is usually necessary for a particular task. AWS Identity and Access Management (IAM) roles offer a solution to both problems.
CloudWatch is an Amazon Web Services (AWS) service that automatically collects a wide range of performance and health data about your AWS resources. This data is available through an API, and also can be viewed as graphs on the AWS console. However the graphs are located on the separate console pages for each type of resource (e.g. EC2, RDS, load balancer, etc). The dispersed locations make it impossible to have a single dashboard view of multiple AWS resources.