.svg)
.svg)
An AWS CloudWatch event bus is a feature that facilitates AWS accounts to share events with each other.Amazon CloudWatch event buses are configured to allow access only to friendly AWS accounts in order to prevent unauthorized users from sharing their CloudWatch events. This is AWS best Paractice to notifiy if the Amazon CloudWatch default event bus created within your account allows unknown cross-account event delivery.
An AWS CloudWatch default event bus is a feature that facilitates AWS accounts to share events with each other. This is template notify if your CloudWatch default event bus available within your AWS account allows access to everyone (*). This is AWS best practice to allow only the authorized users to send their events data by managing the permissions defined for the default event bus.
This workflow sends an automated report of RDS instances that are low on storage. Detecting RDS database instances that run low on disk space is crucial when these instances are used in production by latency-sensitive applications as this can help you take immediate actions and expand the storage space in order to maintain an optimal response time. This is an important part of your monitoring setup.
The workflow retrieves all the RDS DB instances and monitors their storage state with the “AWS monitoring” node, all the instances that are found to be low on storage are filtered and sent to the Report node which will be used to notify you of the appropriate instances. The workflow is set up in a fully no-code fashion, where the ‘Monitoring Node’ directly integrates and sends you monitoring data in a readable format. The data can be retrieved for any resource or sub-resource.
The workflow consists of 5 nodes. The workflow is set to be triggered by an external application (Jira ticket, Email etc). As soon as the resource node collects all the instances (you can filter out instances to be retrieved using Additional Parameters), the AWS monitoring node has all the parameters set to monitor your instances. Subsequently, the low storage instances are filtered out with the custom function written on the filter node. The Report node sends an Email/Slack notification to the user.
It is an AWS best practice to launch every EC2 machine in an AWS Auto Scaling Group to achieve zero downtime. This workflow sends a report of instances not launched in an auto-scaling group.
It is an AWS best practice to launch EC2 machine from an approved/golden AMI. Approved AMI is an image of an EC2 Instance containing all the necessary software and settings configured for your application; which helps in scaling, and quick & secure deployment.
Notifies that whether your Amazon Auto Scaling Groups (ASGs) span across multiple Availability Zones (AZs) within an AWS region. This is AWS best practice to expand the availability of your auto-scaled applications. When hosting your AWS ASGs within a multi-AZ environment, if one AZ becomes unhealthy or unavailable, the Auto Scaling Group launches new EC2 instances in an unaffected Availability Zone, enhancing the availability and reliability of the ASG.
.svg)
Make sure the number of ElastiCache cluster cache nodes provisioned in your AWS account has not reached the limit set by your organization. Monitoring and setting limits will assist you to handle your resources better and avoid unforeseen costs in your AWS bill.
Setting limits for the type of AWS ElasticSearch instances will help you address internal compliance requirements and prevent unexpected charges on your AWS bill. Ensure that your existing AWS instances and dedicated master have the desired type established by your organization based on the caching workload required.
.svg)
.svg){kind=small}
.svg)
