Alarm States
An alarm can be in one of the three following states at any given time:
ALARM The data points to alarm have crossed and remained past a defined threshold for a period of time.
OK The data points to alarm have not crossed and remained past a defined threshold for a period of time.
INSUFFICIENT_DATA The alarm hasn’t collected enough data to determine whether the data points to alarm have crossed a defined threshold. New alarms always start out in an INSUFFICIENT_DATA state. It’s important to remember that an ALARM state doesn’t necessarily indicate a problem, and an OK state doesn’t necessarily indicate the absence of a problem. Alarm states track only whether the data points to alarm have crossed and remained past a threshold for a period of time.
Data Points to Alarm and Evaluation Period
The period of time a data point to monitor must remain crossing the threshold to trigger an alarm state change depends on the data points to alarm . As an example, if the period is five minutes and the data points to alarm is three, then the data points to monitor must cross and remain crossing the threshold for 15 minutes before the alarm goes into an ALARM state. There are cases where you may want to trigger the alarm if a data point to monitor crosses the threshold periodically but doesn’t remain past it. For this, you can set an evaluation period that’s equal to or greater than the data points to alarm. Suppose you
want to trigger an alarm if the data points to monitor cross the threshold for three out of five data points. You would set the evaluation period to 5. The alarm would trigger if any three of the latest five data points exceed the threshold. The exceeding values don’t have to be consecutive. This is called an m out of n alarm , where m is the data point to alarm and n is the evaluation period. The evaluation period can’t exceed 24 hours. To give an illustration, let’s say you create an alarm with a threshold of >= 40. The data points to alarm is 2, and the evaluation period is 3. Now suppose CloudWatch evaluates the following three consecutive data points: 46, 39, and 41. Two of the three data points exceed the threshold, so the alarm will transition to the ALARM state. Following that, CloudWatch evaluates the consecutive data points 45, 30, and 25. Two of the three data points fall below the threshold, so the alarm transitions to an OK state.
Notice that CloudWatch must evaluate three data points (the evaluation period) before it changes the alarm state.
Missing Data
Missing data can occur during an evaluation period. This may happen if you detach an EBS volume from or stop an instance. CloudWatch offers the following four options for how it evaluates periods with missing data:
As Missing This treats the period missing data as if it never happened. For instance, if over four periods the data points are 41, no data, 50, and 25, CloudWatch will remove the period with no data from consideration. If the evaluation period is 3, it will evaluate only three periods with the data points 41, 50, and 25. It will not consider the missing data as occurring in the evaluation period. This is the default setting.
Not Breaching Missing data points are treated as not breaching the threshold. Consider a three out of four alarm with a threshold <40, given the same data points: 41, no data, 50, and 25. Even though two values are breaching, the alarm would not trigger because the missing data is assumed to be not breaching.
Breaching CloudWatch treats missing data as breaching the threshold. Using the preceding illustration, the alarm would trigger, as three of the four values would exceed the threshold.
Ignore The alarm doesn’t change state until it receives the number of consecutive data points specified in the data points to alarm setting.
Actions
You can configure an alarm to take an action when it transitions to a given state. You’re not limited to just when an alarm goes into an ALARM state. You can also have CloudWatch take an action when the alarm transitions to an OK state. This is useful if you want to receive a notification when CPU utilization is abnormally high and another when it returns to normal. You can also trigger an action when an alarm monitoring an instance goes into an INSUFFICIENT_DATA state, which may occur when the instance shuts down. You can choose from the following actions:
Notification Using Simple Notification Service The Simple Notification Service (SNS) uses communication channels called topics. A topic allows a sender or publisher to send a notification to one or more recipients called subscribers. A subscriber consists of a protocol and an endpoint. The protocol can be HTTP, HTTPS, Simple Queue Service (SQS), Lambda, a mobile push notification, email, email-JSON, or short message service (SMS). The endpoint depends on the protocol. In the case of email or email-JSON, the endpoint would be an email address. In the case of SQS, it would be a queue. The endpoint for HTTP or HTTPS would be a URL. When creating an alarm action, you specify an SNS topic. When the alarm triggers, it sends a notification to the topic. SNS takes care of relaying the notification to the subscribers of the topic.
Auto Scaling Action If you’re using Auto Scaling, you can create a simple Auto Scaling policy to add or remove instances. The policy must exist before you can select it as an alarm action.
EC2 Action You can stop, terminate, reboot, or recover an instance in response to an alarm state change. You might choose to monitor the AWS/EC2 StatusCheckFailed_ Instance metric, which returns 1 if there’s a problem with the instance, such as memory exhaustion, file system corruption, or incorrect network or startup configuration. Such issues could be corrected by rebooting the instance. You might also monitor the StatusCheckedFailed_System metric, which returns 1 when there’s a problem that requires AWS involvement to repair, such as a loss of network connectivity or power, hypervisor problems, or hardware failure. In response to this, the recover action migrates the instance to a new host and restarts it with the same settings. In-memory data is lost during this process. EC2 actions are available only if the metric you’re monitoring includes the InstanceId as a dimension, as the action you specify will take place against that instance. Using an EC2 action requires a service-linked role named AWSServiceRoleForCloudWatchEvents, which CloudWatch can create for you when you create the alarm. Although a single alarm can have multiple actions, it will take those actions only upon transition to a single state that you specify when configuring the alarm. You cannot, for instance, set one action when an alarm transitions to an ALARM state and another action when it transitions to an OK state. Instead, you’d have to create two separate alarms.
AWS Config
AWS Config tracks how your AWS resources are configured at a point in time. Resources are entities that you create and manage using the management console, AWS CLI, or AWS SDKs. Think of AWS Config as a time machine. You can use it to see what a resource configuration looked like at some point in the past versus what it looks like now. It can also show you how your resources are related to one another so that you can see how a change in one resource might impact another. For instance, suppose you create an EBS volume, attach it to an instance, and then later detach it. You can use AWS Config to see not only exactly when you created the volume but when it was attached to and detached from the instance. CloudTrail logs events, and CloudWatch can alert on events, but only AWS Config gives you a holistic view of your resources and how they were configured at any point in time. AWS Config can help you with the following objectives:
Security AWS Config can notify you whenever a resource configuration changes, alerting you to potential breaches. You can also see what users had which permissions at a given time.
Easy Audit Reports You can provide a configuration snapshot report from any point in time. Troubleshooting You can analyze configurations around the time a problem started. AWS Config makes it easy to spot misconfigurations and how a problem in one resource might impact another.
Change Management AWS Config lets you see how a potential change to one resource could impact another. For example, if you plan to change a security group, you can use AWS Config to quickly see all instances that use it.
The Configuration Recorder
The configuration recorder is the workhorse of AWS Config. It discovers your existing resources, records how they’re configured, monitors for changes, and tracks those changes over time. By default, it monitors all items in the region in which you configure it. It can also monitor the resources of global services such as IAM. If you don’t want to monitor all resources, you can select specific resource types to monitor, such as EC2 instances, IAM users, S3 buckets, or DynamoDB tables. You can have only one configuration recorder per region.
Configuration Items
The configuration recorder generates a configuration item for each resource it monitors. The configuration item contains the specific settings for that resource at a point in time, as well as the resource type, its ARN, and when it was created. The configuration item also includes the resource’s relationships to other resources. For example, a configuration item for an EBS volume would include the instance ID of the instance it was attached to at the time the item was recorded. AWS Config maintains configuration items for every resource it tracks, even after the resource is deleted. Configuration items are stored internally in AWS Config, and you can’t delete them manually.
Configuration History
AWS Config uses configuration items to build a configuration history for each resource. A configuration history is a collection of configuration items for a given resource over time. A configuration history includes details about the resources, such as when it was created, how it was configured at different points in time, and when it was deleted, if applicable. It also includes any related API logged by CloudTrail. Every six hours in which a change occurs to a resource, AWS Config delivers a configuration history file to an S3 bucket that you specify. The S3 bucket is part of what AWS calls the delivery channel. Files are grouped by resource type. The configuration history for all EC2 instances goes into one file, while the history for EBS volumes goes into another. The files are timestamped and kept in separate folders by date. You can also view configuration history directly from the AWS Config console. You can optionally add an SNS topic to the delivery channel to have AWS Config notify you immediately whenever there’s a change to a resource.
Also read this topic: Introduction to Cloud Computing and AWS -1
Configuration Snapshots
A configuration snapshot is a collection of all configuration items from a given point in time. Think of a configuration snapshot as a configuration backup for all monitored resources in your account. Using the AWS CLI you can have AWS Config deliver a configuration snapshot to the bucket defined in your delivery channel. By default, the delivery channel is named default, so to deliver a configuration snapshot, you would manually issue the following command: aws configservice deliver-config-snapshot –delivery-channel-name default AWS Config can automatically deliver a configuration snapshot to the delivery channel
at regular intervals. You can’t set automatic delivery of this in the console but must configure this using the CLI. To do this, you must also specify a JSON file containing at a minimum the following items:
■ Delivery channel name (default)
■ S3 bucket name
■ Delivery frequency of the configuration snapshot
The file may also optionally contain an SNS ARN. Let’s refer to the following file as deliveryChannel.json:
{
“name”: “default”,
“s3BucketName”: “my-config-bucket-us-east-1”,
“snsTopicARN”: “arn:aws:sns:us-east-1:account-id:config-topic”,
“configSnapshotDeliveryProperties”: {
“deliveryFrequency”: “TwentyFour_Hours”
}
}
The delivery frequency can be every hour or every 24, 12, 6, or 3 hours. To reconfigure the delivery channel according to the settings in the deliveryChannel.json file, you’d issue the following command: aws configservice put-delivery-channel –delivery-channel file://deliveryChannel .json To verify that the configuration change succeeded, issue the following command: aws configservice describe-delivery-channels If the output matches the configuration settings in the file, then the configuration change was successful.
Monitoring Changes
The configuration recorder generates at least one new configuration item every time a resource is created, changed, or deleted. Each new item is added to the configuration history for the resource as well as the configuration history for the account. A change to one resource will trigger a new configuration item for not only the changed resource but also related resources. For instance, removing a rule in a security group causes the configuration recorder to create a new item for the security group and every instance that uses that security group. Although you can’t delete configuration items manually, you can configure AWS Config to keep configuration items between 30 days to 7 years. Seven years is the default. Note that the retention period does not apply to the configuration history and configuration snapshot files AWS Config delivers to S3.
Starting and Stopping the Configuration Recorder
You can start and stop the configuration recorder at any time using the web console or the CLI. During the time the configuration recorder is stopped, it doesn’t monitor or record changes. But it does retain existing configuration items. To stop it using the following CLI command, you must specify the configuration recorder’s name, which is default. aws configservice stop-configuration-recorder –configuration-recorder-name default To start the recorder, issue the following command: aws configservice start-configuration-recorder –configuration-recorder-name default
Recording Software Inventory
AWS Config can record software inventory changes on EC2 instances and on-premises servers. This includes the following:
■ Applications
■ AWS components like the CLI and SDKs
■ The name and version of the operating system
■ IP address, gateway, and subnet mask
■ Firewall configuration
■ Windows updates
To have AWS Config track these changes, you must enable inventory collection for theserver using the EC2 Systems Manager. You also must ensure AWS Config monitors the SSM: ManagedInstanceInventory resource type.
Managed and Custom Rules
In addition to monitoring resources changes, AWS Config lets you specify rules to define the optimal baseline configuration for your resources. AWS Config also provides customizable, predefined rules that cover a variety of common scenarios. For example, you may want to verify that CloudTrail is enabled, that every EC2 instance has an alarm tracking the CPUUtilization metric, that all EBS volumes are encrypted, or that multifactor authentication (MFA) is enabled for the root account. If any resources are noncompliant, AWS Config flags them and generates an SNS notification. When you activate a rule, AWS Config immediately checks monitored resources against the rules to determine whether they’re compliant. After that, how often it reevaluates resources is based on how the rule is configured. A reevaluation can be triggered by configuration changes or periodically. Periodic checks can occur every hour or every 3, 6, 12, or 24 hours. Note that even if you turn off the configuration recorder, periodic rules will continue to run.
People also ask this Questions
- What is a defense in depth security strategy how is it implemented?
- What is AWS Solution Architect?
- What is the role of AWS Solution Architect?
- Is AWS Solution Architect easy?
- What is AWS associate solutions architect?
- Is AWS Solutions Architect Associate exam hard?
Infocerts, 5B 306 Riverside Greens, Panvel, Raigad 410206 Maharashtra, India
Contact us – https://www.infocerts.com
