如果您想加入「AWS爱好者」微信群和其他同学交流，请加微信:chenmoemo，后拉入「AWS爱好者」微信群。

我们上篇文章——<<AWS Limit Monitor，主动跟踪资源使用情况，接近limits时推送通知提醒>>讨论了AWS Limit Monitor，该解决方案自动配置必要的服务，以便在您使用AWS的过程中，主动跟踪资源使用情况当使用的资源接近limits限制时发送通知，帮助您避免有启动资源需求时才发现limits到上限造成无法启动资源从而影响线上业务的情况。

今天我们实战，对AWS Limit Monitor进行自动化部署。

AWS Limit Monitor部署

首先，在部署 AWS Limit Monitor前，请仔细查看上篇关于 AWS Limit Monitor理论内容，包括 AWS Limit Monitor架构说明等，这会有助于顺利完成部署工作。

/本次部署演示不包括部署secondary账户和slack推送内容，如有实际需求，针对对应配置项进行配置即可。/

启动堆栈，开始部署

下面提供的 AWS CloudFormation 模版自动部署AWS Limit Monitor到您的账户中。

/Note：注意，部署会产生aws资源使用费用，具体费用数额请查看本方案使用各个服务的具体费用。如果是测试目的，部署完成后请将所有相应资源删除以免产生不必要的费用。/

1、登陆aws管理控制台后，复制下面链接后在浏览器中打开，启动AWS Limit Monitor AWS CloudFormation template

https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=LimitMonitor&templateURL=https:%2F%2Fs3.amazonaws.com%2Fsolutions-reference%2Flimit-monitor%2Flatest%2Flimit-monitor.template

也可以通过下面链接下载模板用于你自己的环境。

https://s3.amazonaws.com/solutions-reference/limit-monitor/latest/limit-monitor.template

2、默认情况下，模板在US East (N. Virginia) Region启动。

3、在创建堆栈页面，确认下正确的模板 URL 显示在 Amazon S3 URL 文本框中，然后选择”下一步”。

4、可以修改堆栈名称，我们这里就用默认的。

5、参数设置部分，如有需要可进行自行调整，参数配置说明：

• Account List，limit 监控的账号ID列表，用引号和逗号分隔，如果您需要部署secondary账户limit监控的话就要将账号ID配置到这里。我将这里留空，留空表示只监控当前主账户的limit。
• Email Notification Level，配置出发通知的事件级别，这里留默认“WARN”, “ERROR”，表示达到这两个级别时出发通知。
• Email Address，这是必选项，表示接收 Amazon SNS 通知的有效电子邮件地址。
• 后面三个选项是关于slack的配置，我们不进行配置，留空。

6、审核LimitMonitor页面，

注意页面最下方，勾选两个复选框以提供给CloudFormation相应权限。

7、点击创建堆栈，开始部署，可以在AWS CloudFormation控制台查看部署状态，整个部署过程大约5分钟左右，您将能看到f *CREATE_COMPLETE*。

创建完成：

查看下事件日志无异常后，我们进行下一步。

8、此时，在您部署时填写的邮箱中，应该能够收到一封订阅确认邮件，点击订阅url链接启动Amazon SNS notifications。注意，只有完成这一步当LimitMonitor有报警的时候才能收到订阅通知。

至此， AWS Limit Monitor就部署完成了，我们接下来确认下AWS Limit Monitor各个组件是否成功部署。

部署结果确认

1、首先我们打开lambda控制台，我们看到相应的函数已经成功部署。

点击具体的函数后，可以看到对应函数具体的结构和信息。

2、进入CloudWatch控制台，CloudWatch规则已经成功创建。

3、进入SNS控制台，看到主题已经创建好，要确认已完成订阅，才能收到推送消息。

4、进入SQS控制台，可以看到时间队列和死信队列已经创建完成。

5、进入DynamoDB控制台，看到表已经创建成功。所有AWS成功创建。

AWS Limit Monitor提供一些自定义配置，帮助客户细微调整以满足实际业务需求。

AWS Limit Monitor自定义配置

1、调整lambda运行间隔

默认情况下，AWS Lambda函数每24小时运行一次以刷新AWS Trusted Advisor服务限制检查。但是，您可以通过更改AWS CloudFormation模板中的映射来更改Lambda函数的调用频率。注意：如果调整为12小时内，那么事件到达Amazon DynamoDB可能会有延迟。

要更改时间间隔，请在AWS CloudFormation模板中修改以下映射：

RefreshRate:>    
CronSchedule:>       
Default: rate(1 day)

2、调整需要监控的服务

默认情况下，此解决方案检查AWS Trusted Advisor检查的所有服务限制。要指定您要检查的服务限制，请修改以下AWS CloudFormation模板映射。

EventsMap:>    
Checks:>      
Services:>          ‘”AutoScaling”,”CloudFormation”,”DynamoDB”,”EBS”,”EC2”,”ELB”,”IAM”,”Kinesis”,”RDS”,”Route53”,”SES”,”VPC”’

完成以上步骤，那么我们部署的AWS Limit Monitor已经可以正常运作了。

/Note：/

/要使用此解决方案，AWS帐户必须具有Business或Enterprise 的AWS Support，才能访问Trusted Advisor服务limits检查。/

以上，就是我们今天的AWS Limit Monitor部署实操，希望能给大家带来帮助。如果大家是测试目的，请在测试后将所有AWS Limit Monitor创建的资源删除，以免产生不必要的费用。方式是先删除CloudFormation堆栈，然后进入各个服务的控制台检查创建的各个资源进行删除。

如果您想加入「AWS爱好者」微信群和其他同学交流，请加微信:chenmoemo，后拉入「AWS爱好者」微信群。

我们今天讨论的主题是AWS Limit Monitor，该解决方案会自动配置必要的服务，以便在您使用AWS的过程中，当使用的资源接近limits限制时主动跟踪资源使用情况并发送通知，帮助您避免有启动资源需求时才发现limits到上限造成无法启动资源从而影响线上业务的情况。

什么是AWS service limits(服务限制)?

为帮助AWS所有客户提供高可用性，可靠性和强健的服务，并最大程度地减少新客户的账单风险，Amazon Web Services（AWS）维护每个帐户的服务限制，也就是service limits。

登陆AWS控制台，选择EC2服务，然后点击左侧“限制”后，可以看到EC2服务相关的limits信息。那什么是limits呢？如图中“正在运行按需 t2.micro”，限制类型为“正在运行的实例”，当前限制为20，是指按需T2.micro，在当前的账号，在当前区域，您正在运行的实例最大限制为20个，如果要超过20个就需要提前向AWS申请提升limits。

AWS设置limits是为了避免客户因为恶意攻击或者脚本操作失误等等造成开启大量资源产生账单风险。

几乎每项AWS服务都是根据您在给定时间可以在特定AWS区域内启动多少资源来控制的。但是，有时即使是最有经验的AWS客户也可能会意外达到服务限制，因为申请开limits无法实时生效，那就会导致无法启动新资源，对业务造成影响。所以如何能够主动跟踪AWS账户的资源使用情况，当接近limits的时候主动推送提醒，让我们第一时间收到提醒，这个解决方案就产生了：

AWS Limit Monitor解决方案

为了根据服务限制更主动地跟踪其AWS资源使用情况，AWS提供了AWS Limit Monitor解决方案，该方案会自动配置必要的服务，以便在接近limits限制时主动跟踪资源使用情况并发送通知。而且该解决方案易于部署，利用AWS Trusted Advisor服务Limits检查和服务配额来帮助您显示特定AWS服务的使用情况和Limits，并集中管理您的Limits。借助AWS Limit Monitor，您可以接收电子邮件通知或将通知发送到现有的Slack，从而使您可以请求增加Limits或在达到Limits之前关闭资源。

Note：

要使用此解决方案，AWS帐户必须具有Business或Enterprise 的AWS Support，才能访问Trusted Advisor服务limits检查。

AWS Limit Monitor架构概述

部署此解决方案将会在AWS Cloud中构建以下环境。

介绍一下这个方案的架构，上面这个架构图看着比较复杂，其实很多都是可选项，在您的业务不需要管理Secondary账户limits、slack推送或vCPU limits时可以不对这些单项内容进行配置。

基础架构非常简单，AWS Limit Monitor包括一个在主账户中部署的模板。该模板会启动一个AWS Lambda函数，该函数每24小时运行一次。（调用频率可通过AWS cloudFormation模板调整）。Lambda函数通过API调用刷新AWS Trusted Advisor服务limits检查，获取最新的使用情况和limits数据。Trusted Advisor将根据limits和使用情况计算使用量，以确定状态是正常（使用率低于80％），警告（使用率在80％至99％之间）还是错误（使用率100％），这个就是这个架构的核心的功能。

最近aws对于limits做了一些调整，登陆控制台后进入到EC2的-限制页面，在页面最上面就会收到通知以及调整的内容：

简单的说就是从实例计数limits调整为vCPU计数限制（由于此调整不是本文重点，故不赘述），在我们这个AWS Limit Monitor方案中，如果您选择监视基于Amazon Elastic Compute Cloud（Amazon EC2）的虚拟中央处理器（基于vCPU）的限制，则模板将启动另一个Lambda函数，该函数每五分钟运行一次。该功能检查服务配额以检索每个AWS区域的vCPU使用率和limits数据。该函数根据limits计算vCPU使用率，以确定状态是“正常”（利用率低于80％），“警告”（利用率在80％至99％之间）还是“错误”（利用率100％）。

前面介绍了两个Lambda函数的功能，然后由Amazon CloudWatch Events从Trusted Advisor和vCPU监视Lambda函数捕获状态事件，并使用一组CloudWatch Events规则将状态事件发送到您在解决方案的初始部署期间选择的所有目标：Amazon Simple Queue Service（Amazon SQS）队列，Amazon Simple Notification Service（Amazon SNS）主题（可选）或Slack通知的Lambda函数（可选）。

Amazon SQS接收所有OK，WARN和ERROR状态事件，并将它们发送到存储事件的Amazon DynamoDB表。默认情况下，Amazon SNS和Slack仅接收WARN和ERROR状态事件。但是，您可以根据自己的特定需求自定义通知。

以上，就是AWS Limit Monitor方案的架构及组成部分。

如果在初始部署期间启用了Slack通知，则该解决方案将启动一个Lambda函数，该函数将通知发送到您现有的Slack频道。还将部署一个AWS Systems Manager参数存储，以为Slack WebHook URL提供高可用性，安全，持久的存储，该URL用于将消息发送到Slack通道。

以上就是AWS Limit Monitor的架构组成部分。

支持多AWS账户架构

该解决方案还包括一个secondary模板，您可以将其部署在您的secondary账户和其他AWS区域中。可以对多账户进行limits集中管理，追踪资源的使用情况，接近limits时推送通知。

secondary模板会启动一个Lambda函数，该函数刷新secondary帐户中的Trusted Advisor服务limits检查。如果启用，此模板还将启动一个Lambda函数，以检查服务配额中的vCPU限制。secondary帐户中的CloudWatch Events捕获这两个功能的状态事件，并使用CloudWatch Event Bus将这些事件发送到主帐户。在主帐户中收到这些事件后，CloudWatch Events规则会将事件发送到您选择的目标。

以上，今天我们介绍了AWS Limit Monitor解决方案的内容，AWS Limit Monitor能让我们轻松管理和跟踪limits使用情况，接近limits上限推送提醒，避免了有启动资源需求时才发现limits到上限造成无法启动资源从而影响线上业务的情况，希望能够给大家带来帮助。

本文AWS Limit Monitor的后续内容，实际演示部署AWS Limit Monitor解决方案，我们下次再见吧。