在人工智能的世界中,迁移学习是一种强大的方法。它利用已有模型的知识来适应新的任务,类似于一个学生用他已有的知识去理解新的科目。这种方法的优势在于可以减少训练数据的需求,降低计算资源的消耗,并加快模型收敛的速度。

微调是迁移学习的进一步应用,专注于对模型进行特定任务的调整。就像为学生提供专门的辅导,帮助他在某个领域中更加出色。微调使模型在特定任务中表现得更精准。

在指令式微调中,我们有两种会话方式：单轮会话和多轮会话。单轮会话是一种一问一答的形式,每次对话相互独立,适合简单的查询场景。而多轮会话则保持上下文的连贯性,支持追问和补充,适合更复杂的交互场景。

数据在AI训练中扮演着重要角色。标记样本是指带有正确答案的数据,用于微调模型。比如,输入”患者出现发热、咳嗽症状”时,标记的输出可能是”建议进行发烧检测,并及时就医”。这些数据质量高,但制作成本也高,适用于有监督学习。

相对而言,未标记样本是没有标注答案的原始数据,如大量文本文档、网页内容和对话记录。这些数据获取成本低、数量庞大,适用于无监督学习,通过这些数据,预训练模型可以提升其基础能力。

结合这些概念,AI模型能够通过不同的训练和调整方式,更好地理解和处理各种任务和对话。在现代AI应用中,了解并善用这些技术,将大大提高模型的效率和效果。

迁移学习（Transfer Learning）

• 定义：将一个领域学到的知识迁移到另一个相关领域
• 优势：
  • 减少训练数据需求
  • 降低计算资源消耗
  • 加快模型收敛速度

单轮和多轮会话

• 单轮会话：
  • 一问一答的形式
  • 每次对话相互独立
  • 适合简单查询场景
• 多轮会话：
  • 保持上下文连贯性
  • 支持追问和补充
  • 适合复杂交互场景

标记样本和未标记样本

标记样本（Labeled Samples）

• 定义：已经人工标注了正确答案或期望输出的训练数据
• 示例：
  • 输入：”患者出现发热、咳嗽症状”
  • 标记：”建议进行发烧检测,并及时就医”
• 特点：
  • 数据质量高
  • 制作成本高
  • 适用于有监督学习

未标记样本（Unlabeled Samples）

• 定义：没有人工标注答案的原始数据
• 示例：
  • 大量的文本文档
  • 网页内容
  • 对话记录
• 特点：
  • 获取成本低
  • 数量庞大
  • 适用于无监督学习

基本概念对比

持续预训练（Continuous Pre-training）：

• 定义：在原始预训练模型基础上，使用新数据继续进行大规模预训练
• 目的：扩展和更新模型的基础知识
• 数据类型：主要使用未标记数据
• 训练方式：自监督学习

模型微调（Fine-tuning）：

• 定义：针对特定任务或领域，对预训练模型进行小规模定向训练
• 目的：提升模型在特定任务上的表现
• 数据类型：主要使用标记数据
• 训练方式：有监督学习

具体用例对比

持续预训练用例：

`案例1：更新知识库

• 场景：医疗领域新研究文献更新
• 做法：使用最新医学文献进行持续预训练
• 效果：模型掌握最新医学发展

案例2：新领域适应

• 场景：进入新的市场或行业
• 做法：使用该行业的专业文档进行预训练
• 效果：模型理解行业特定术语和知识

案例3：语言扩展

• 场景：增加新的语言支持
• 做法：使用目标语言的大量文本进行预训练
• 效果：模型获得新语言能力

模型微调用例：

`案例1：客服机器人

• 场景：企业特定产品支持
• 数据：问题-答案对
• 效果：准确回答产品相关问题

案例2：法律助手

• 场景：特定法律文书生成
• 数据：文书模板和示例
• 效果：生成规范的法律文档

案例3：代码补全

• 场景：特定编程语言补全
• 数据：代码片段对
• 效果：提供准确的代码建议`

核心区别

训练规模：

• 持续预训练：大规模训练
• 模型微调：小规模定向训练

数据要求：

• 持续预训练：大量未标记数据
• 模型微调：少量高质量标记数据

学习目标：

• 持续预训练：通用能力提升
• 模型微调：特定任务优化

选择建议

何时选择持续预训练：

• 有大量新领域数据需要学习
• 需要更新模型的基础知识
• 要扩展模型的语言能力
• 有充足的计算资源

何时选择模型微调：

• 有明确的任务目标
• 有高质量的标记数据
• 需要快速适应特定场景
• 计算资源有限

最佳实践流程：

1. 先进行持续预训练扩展基础能力
2. 再进行模型微调优化具体任务
3. 定期评估效果并调整策略
4. 持续收集反馈进行优化

这种理解和区分对于在AWS Bedrock上开发AI应用非常重要，能帮助我们根据实际需求选择合适的训练策略。

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

我们在使用CloudFront的案例中，为了保障CloudFront的高可用，一般会配置多个源站，当其中一个源站出现故障时，回源需要切换到正常的源站从而不会影响到业务，其实在2018年11月20日，CloudFront推出了一个功能为源故障转移，不需要借助其他系统就可以实现源站的故障转移。

利用 CloudFront 的源故障转移功能，您可以为您的分配设置两个源 – 主要源和辅助源。这样，当 CloudFront 检测到您的主要源不可用时，您的内容将从您的辅助源提供。实现方式为在CloudFront创建一个/源组/，您将在其中为 CloudFront 指定主源以及 CloudFront 将在主源返回特定 HTTP 状态代码故障响应时自动切换到的次要源。

源组中的两个源可以是以下源的任意组合：AWS 源（如 Amazon S3 存储桶或 Amazon EC2 实例）或自定义源（如您自己的 HTTP Web 服务器）。在创建源组时，将 CloudFront 配置为在主源返回您配置的特定状态代码时故障转移到 GET、HEAD 和 OPTIONS HTTP 方法的次要源。

CloudFront 将所有传入请求路由至主源，仅在尝试路由至主源时返回为故障转移或超时配置的状态代码的情况下，CloudFront 才将请求发送到次要源。

实现源故障转移功能创建源组操作非常简单，在CloudFront分配中：

1. 创建源组
2. 添加主/备源
3. 选择故障转移条件

就搞定啦，如图：

如果您想加入「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解决方案，我们下次再见吧。

我们今天介绍AWS置放群组知识点。

在我们启动EC2实例的时候，EC2 服务会尝试以某种方式放置实例，以便将所有实例分布在基础硬件上以最大限度减少相关的故障，AWS有缺省的放置规则，缺省即可满足绝大部分的使用需求。

但是，如果我们想要尽量将我们启动的EC2放置在同一个可用区相互靠近一点，以实现低延迟的网络性能，或者将一些实例严格放置在不同的硬件上以减少相关的故障呢？能不能实现？当然可以，使用本文介绍的AWS的置放群组，根据工作负载类型，您可以使用以下置放策略之一创建置放群组：

• 集群 – 将一个可用区中靠近的实例打包在一起。通过使用该策略，工作负载可以实现所需的低延迟网络性能，以满足 HPC 应用程序通常使用的紧密耦合的节点到节点通信的要求。 
• 分区 – 将实例分布在不同的逻辑分区上，*以便一个分区中的实例组不会与不同分区中的实例组使用相同的基础硬件。*该策略通常为大型分布式和重复的工作负载所使用，例如，Hadoop、Cassandra 和 Kafka。 
• 分布 – 将一小组实例严格放置在不同的基础硬件上以减少相关的故障。 
  
  

下图为我自己建立的置放群组，集群/分区/分布各1个。

接下来将分别介绍三种放置策略：

集群置放群组

集群置放群组是单个可用区中的实例的逻辑分组。按照AWS官方的资料所述，置放群组内的所有节点都可以以 10 Gpbs 流和 25 次聚合的全线速率与该置放群组内的所有其他节点进行通信，而不会由于超额订阅而发生任何减速。

下图显示放入集群置放群组中的实例。

集群置放群组是将启动的EC2实例尽量放置在一起—同一机柜或者相邻机柜，减少实例间的物理距离，一般用于从低网络延迟和/或高网络吞吐量中受益的应用程序，以及在大部分网络流量处于该组中的实例之间的情况下，建议使用集群置放群组。

分区置放群组

在使用分区置放群组时，Amazon EC2 将每个群组划分为多个逻辑段（称为“分区”）。Amazon EC2 确保置放群组中的每个分区具有自己的一组机架。每个机架具有自己的网络和电源。置放群组中的任何两个分区将不会分享相同的机架，从而让您可以在您的应用程序中隔离硬件故障的影响。

下图是单个可用区中的分区置放群组简单的直观表示。它显示了放入到一个分区置放群组的实例，该置放群组具有三个分区 — *分区 1*、*分区 2* 和 *分区 3。每个分区均包含多个实例。一个分区中的实例不与其他分区中的实例共享机架，这使您可以将单一硬件故障的影响限定在相关的分区内。

可使用分区置放群组跨不同机架部署大型分布式和重复的工作负载，例如 HDFS、HBase 和 Cassandra。当您在分区置放群组中启动实例时，Amazon EC2 将尝试跨您指定数量的分区均匀分发实例。您还可以在特定分区中启动实例，以更好地控制实例的放置位置。

分区置放群组可以在同一区域的多个可用区中具有分区。对于每个可用区，一个分区置放群组最多可具有 7 个分区。

分布置放群组

分布置放群组可以将每个实例放置在不同的机架上，并且每个机架具有各自的网络和电源。

下图显示单个可用区中的 7 个实例，这些实例已放入一个分布置放群组。7 个实例放置在 7 个不同的机架上。

建议在具有少量应单独放置的重要实例的应用程序中使用分布置放群组。通过在分布置放群组中启动实例，可以降低在实例具有相同机架时同时发生故障的风险。分布置放群组可以访问不同的机架，因而适合混用不同类型的实例或随着时间的推移启动实例。

分布置放群组可以跨越同一区域中的多个可用区。每个群组在每个可用区中最多有 7 个正在运行的实例。

以上，置放群组的内容就介绍完了，那么如何将EC2实例放置到群组中呢？

在启动EC2实例的配置实例步骤中可以选择将EC2实例添加到置放群组，这样EC2实例就在置放群组中了。

对了，创建置放群组无需支付费用，小伙伴们用起来吧！

今天我们讨论的主题是AWS Personal Health Dashboard，AWS Personal Health Dashboard可在AWS遇到可能会影响您的事件时提供提醒和修正指导。

Service Health Dashboard

相信很多人都接触过AWS的Service Health Dashboard页面，这个页面发布最新的AWS的服务的可用性信息。

我们要知道AWS不可能保证所有的后端和提供的服务都能永远保证100%的可用性，而在本人多年使用AWS过程中，也确实有多次是由于AWS后端或底层的服务问题导致了我的生成环境的业务出现问题。

所以当我们的线上业务出现问题时，建议首先需要确认的是，导致问题的原因是AWS的问题，还是我们业务环境自身的问题。

最简单直接的方法，就是通过Service Health Dashboard页面，地址为：https://status.aws.amazon.com，这个页面提供了按照AWS的区域，截止到当前时间，各个AWS区域内不同服务的当前状态（正常？异常）。

如下面的截图中，可以看到当前时间在东京区域的其中一个可用区出现网络问题，对应的Details也有此次时间的详细时间点，和对应的问题描述和AWS处理的情况。

AWS服务对应正常的状况会在Details中内容为“Service is operating normally”，可以通过这个页面非常直观的查询AWS全球各个区域提供的服务的情况。

Service Health Dashboard 是一个AWS提供的全球的，所有提供服务的状态更高层次的仪表盘，它反映的是全球的服务整体的状态。如果我们想更清晰的获得和自己使用服务相关的一个仪表盘，或者想要定制一些通知等功能，在出现问题的时候推送到SNS通知或者lambda进行后续处理，那么就需要使用AWS Personal Health Dashboard—我们接下来讨论的内容。

AWS Personal Health Dashboard 

AWS Personal Health Dashboard ，列出会对您当前使用账号中用到的AWS资源或者使用的服务造成影响或者潜在影响的异常事件。

我们现在登录下AWS控制台，可以看到控制台右上方的铃铛处有橙色的圆点，表示目前账号使用的资源或服务有事件通知，点击铃铛看到提醒包括：未解决问题(Open issues)，计划更改(Scheduled changes)，以及其他通知(Other notifications) 。

点击“查看所有提醒”后，进入 Personal Health Dashboard 页面。发现当前有两个Open issues，如上所述表示目前账号使用的资源或服务有2个AWS事件通知，且当前仍未解决。当当前账号环境相关出现问题时，它会在这些选项卡中提供一个事件列表，我们看到目前AWS账号下目前的2个open issues一个是RDS相关，一个是EC2相关。

AWS Personal Health Dashboard 会提供影响账户的 AWS 运行状况 事件的相关信息。信息会以两种方式显示：显示按类别组织的最近和未来事件的控制面板（包括Open issues，Scheduled changes，Other notifications），以及显示过去 90 天内所有事件的完整事件日志（Event log) 。

Personal Health Dashboard 会分三组管理问题：未处理问题（Open issues）、已计划更改（Scheduled changes）和其他通知（Other notifications）。默认情况下，未处理问题和其他通知仅限于开始时间在过去 7 天内的问题，已计划更改组包含正在进行或即将进行的项目。

Personal Health Dashboard 的最左侧的事件日志（Event log）页面会显示适用于您的账户的所有 AWS 运行状况 事件。点击单个时间后会显示所有关于该事件的详细信息，包括时间名称，状态，区域，起止时间等等，右边Details选项卡中包括此事件处理的详细时间点和信息，以及AWS提供给用户的针对此次事件的操作建议。

旁边的Affected resources选项卡，会显示受事件影响的任何 AWS 资源的相关信息。可以看到通过PHD，当我们生产环境出现异常时，可以非常方便的定位问题，以及影响到我们的AWS资源。

所以当我们的业务出现问题时，如果我们没有办法判断是由于我们自身的业务环境还是AWS服务或资源出问题的时候，我的建议是第一步先到Personal Health Dashboard页面，在open issues中查看是否有对应业务出现问题时现象的AWS事件，优先排除AWS的问题。

那么有没有什么方式可以监控AWS运行状况，当运行状况改变的时候自动做出对应响应呢？一些AWS的计划维护任务（Scheduled changes），如果没及时关注到可能会因为AWS的计划维护任务影响到生产环境可用性，有什么方式可以及时收到这些计划任务信息呢？这些就需要下面的Amazon CloudWatch Events内容来实现。

通过 Amazon CloudWatch Events 监控 AWS 运行状况 事件

可以通过Amazon CloudWatch Events检测AWS运行状况事件状态的变更并对其进行响应，在Amazon CloudWatch Events中您可以创建规则，在事件与您在规则指定的值匹配时调用一个或多个目标操作。

可以选择以下类型的目标：

• AWS Lambda 函数
• Kinesis 流
• Amazon SQS 队列
• 内置目标（CloudWatch 警报操作）
• Amazon SNS 主题 
  

我们可以创建多个规则，针对不同的规则调用不同的目标进行响应，比如，可以创建health的IAM服务的状态事件，将IAM相关的事件调用SNS，推送给您企业的负责安全相关的同事；在创建一个RDS服务的状态事件，通过SNS将RDS事件邮件推送给负责数据库的同事，通过这种方式，将相应的事件通知邮件推送给相关的同事，让他们关注并及时的进行响应。

当然也可以针对匹配的事件选择调用lambda事件，通过lambda事件中的脚本逻辑响应，比如当EC2出现health问题时关闭并启动EC2，通过此方式将我们的EC2从故障的宿主机自动迁移出去，正常恢复我们的业务。

接下来我们操作下如何创建规则，以及针对规则配置调用的目标。

第一步，在Personal Health Dashboard页面点击右上角的Set up notifications with CloudWatch Events 。

然后会进入到CloudWatch的规则-创建规则页面。

比如我们要创建一个EC2的health响应，实现EC2出现AWS运行状况事件状态的变更时通过SNS通知我们。

我们在创建规则页面选择“事件模式”，选择事件（按服务），服务名称选择“health”；事件类型选择“特定运行状况事件”，然后选择特定服务-EC2；

然后在页面右侧选择添加目标，我们本例选择SNS主题，然后选择对应的主题后输入规则的名称，完成创建，这样当EC2服务有health事件时，就会SNS邮件推送具体的信息给主题订阅者，让我们在第一时间可以知晓AWS运行状况事件，并对此快速响应保障我们的业务可用性。

以上就是今天的内容，生命不息，学习不止，下次见。

今天参与了一个讨论，内容是在有AWS控制台根用户权限的情况下，能否重置 该账号下的Amazon EC2 实例的密码和SSH 密钥，从而登陆到该EC2系统，主要用于SSH密钥丢失或者密码忘记的情况；

另外现在很多企业的业务有这样的情境，需要和三方公司合作，三方公司负责出AWS资源（EC2），然后供我们企业跑业务，三方公司掌握着AWS控制台根用户权限，我们的企业掌握操作系统权限，这种情况下，三方公司是可以通过AWS控制台根用户权限进入我们企业操作系统并且会造成数据安全问题的。

如何达成呢？使用AWSSupport-ResetAccess，看下官方的简单介绍，然后我们就开始操作：

-AWSSupport-ResetAccess简介-

您可以使用 AWSSupport-ResetAccess文档在 Amazon EC2 Windows 实例上自动重新启用本地管理员密码生成，以及在 Amazon EC2 Linux 实例上生成新 SSH 密钥。AWSSupport-ResetAccess文档旨在执行 Systems Manager 操作、AWS CloudFormation 操作和 Lambda 函数的组合，从而将重置本地管理员密码通常所需的步骤自动化。

您可以使用 Automation 配合 AWSSupport-ResetAccess文档解决以下问题：

Windows

您丢失了 EC2 密钥对：要解决此问题，您可以使用 AWSSupport-ResetAccess文档，从当前实例创建启用了密码的 AMI，从 AMI 启动新实例，然后选择您拥有的密钥对。

您丢失了本地管理员密码：要解决此问题，您可以使用 AWSSupport-ResetAccess 文档生成可以使用当前 EC2 密钥对解密的一个新密码。

Linux

您丢失了 EC2 密钥对，或者配置了对实例的 SSH 访问但丢失：要解决此问题，您可以使用 AWSSupport-ResetAccess 文档创建当前实例的新 SSH 密钥，这使您能够重新连接到该实例。

-AWSSupport-ResetAccess工作原理-

使用自动化和 AWSSupport-ResetAccess文档对实例进行故障排除的工作原理如下：

• 您为实例指定 ID 并运行自动化工作流程。
• 系统创建一个临时 VPC，然后运行一系列 Lambda 函数以配置该 VPC。
• 系统在与您的原始实例相同的可用区内为您的临时 VPC 标识一个子网。
• 系统启动一个临时的启用了 SSM 的 帮助程序实例。
• 系统停止您的原始实例并创建备份。然后，它将原始根卷挂载到帮助程序实例。
• 系统使用 Run Command 在帮助程序实例上运行 EC2Rescue。在 Windows 上，EC2Rescue 通过在附加的原始根卷上使用 EC2Config 或 EC2Launch 为本地管理员启用密码生成。在 Linux 上，EC2Rescue 生成并注入新的 SSH 密钥并将私有密钥加密保存到 Parameter Store 中。完成后，EC2Rescue 重新将根卷挂载回原始实例。/
• 系统根据您的实例创建新 Amazon 系统映像 (AMI)，现在密码生成已启用。您可以使用此 AMI 创建新 EC2 实例，并根据需要关联新密钥对。
• 系统重启您的原始实例，并终止临时实例。系统也将终止临时 VPC 和在自动化开始时创建的 Lambda 函数。
• Windows：您的实例生成一个新密码，您可以使用分配给实例的当前密钥对从 EC2 控制台对该密码进行解码。
• Linux：您可以使用存储在 Systems Manager Parameter Store 中的 SSH 密钥（格式为 *ec2rlopenssh**instance_id**key*），通过 SSH 连接到实例。

-使用AWSSupport-ResetAccess重置EC2(LINUX)密钥-

看着很复杂是不是，其实操作很简单，因为AWS已经将上面的步骤放到了AWS Systems Manager的自动化里面。假设我们下面这台EC2的SSH密钥找不到了，我们用AWSSupport-ResetAccess重置下密钥：

1、进入AWS Systems Manager：

2、然后在自动化里面搜索AWSSupport-ResetAccess，然后进入：

3、选择手动执行，这样可以按照需求执行相应步骤，然后instanceid输入上面实例的id，其他参数如恢复实例类型，VPC，子网，角色默认即可：

4、然后执行相应步骤后等待即可，每个步骤的名称对应着改步骤具体的功能，Linux实例就不要选Windows相关的步骤：

5、全部执行完毕后，新的SSH密钥存储在了参数存储中，将其复制下来，用这个新的密钥即可登录上述测试的实例：

以上 ，使用新生成的SSH密钥，登录了原来的实例。

Application Discovery是收集和了解您业务所在机房环境，确定存在哪些物理和虚拟服务器及数量，这些服务器上运行的操作系统信息、网络信息以及应用程序的过程。

Application Discovery 的收集的过程可以通过手动方式，但是当您的业务所涉及的服务器数量较多且复杂时会导致效率低、周期长，容易出错。因此建议利用自动发现工具，这些发现工具一般都是通过在服务器上安装Agent（第三方或自行开发），可以自动发现所有应用程序和支持基础架构，通过持续运行自动发现工具来规划如何使数据保持最新状态。

那么一般都支持收集服务器哪些信息呢？可以看下最后面的截图如：网络信息如IP、MAC、系统信息如操作系统版本，以及CPU、内存等硬件信息等，自动发现工具主要用于准确掌控组织资产基础信息，且当业务信息变更时及时发现及时更新。如：自动发现工具收集的记录可以和您组织的CMDB系统基础信息进行比对，当检测到变更或不一致时采取相应的策略，最终确保您掌握的业务信息是准确的等等。

第三方自动发现工具有很多，感兴趣的同学可以自行搜索，当然有研发能力的组织也可以自行进行工具的开发。

AWS也有类似的服务，Application Discovery Service（ADS），主要是用于云迁移，我们在这里不探讨此服务的具体功能，只参考ADS能自动发现的信息，为我们提供一些思路。

ADS应用程序发现工具可以：

• 自动发现数据中心中运行的基础架构和应用程序的清单，并通过持续监视系统来维护清单。
• 帮助确定应用程序如何相互依赖或依赖于底层基础架构。
• 用于分析和规划的操作系统和服务的版本。
• 测量在主机上运行的应用程序和进程，以确定性能基准和优化机会。
• 提供对应用程序和服务器进行分类的方法
• 在使CMDB更新时，自动发现工具可以节省时间和精力。
• 随着项目的进展，使资源信息保持最新是关键，而工具有助于减轻这种痛苦。

以下摘自官方Application Discovery Service的文档，主要参考下ADS可以支持收集发现哪些信息：

AWS Application Discovery Agent

AWS Discovery Agent 是安装在本地服务器和 VM 上用于执行发现和迁移的 AWS 软件。代理将捕获系统配置、系统性能、运行中的进程以及系统之间网络连接的详细信息。代理支持大多数 Linux 和 Windows 操作系统，您可以将其部署在物理本地服务器、Amazon EC2 实例和虚拟机上。