Hello大家好，我们今天的课时对AWS的部署方式做一个对比和总结。

部署方式

对于一个专家级解决方案架构师来说，需要有在面对不同的业务需求时，采用适合的部署方案的能力。

我们前面的课时也讲了很多AWS提供的部署服务，接下来我们就做个总结，来看一下都有哪些部署方式以及适用的场景。

User Data

首先，可以通过配置EC2实例的User Data，在第一次启动EC2实例时自定义EC2实例的环境以及应用程序。使用User Data可以做一些简单、常见的配置任务。

但是要注意如果在User Data中要安装和调整的相关步骤太多的话，就会导致实例的启动速度太慢。

创建AMI

在这种情况下，**可以通过创建AMI。**比如如果您需要安装运行环境，如JAVA运行环境，或者需要更新操作系统，安装一些工具等等，所有这些您希望要提前安装部署好的环境和工具，都可以先在一台EC2实例上全部部署/安装好，然后在这台实例创建一个AMI，这样的话将来在启动实例时就可以直接使用这个AMI，这样就会大大的提高部署环境的速度。

这应该很好理解吧，使用AMI是将需要安装的东西都已经装好了，通过做好的AMI启动实例后所有的东西就已经都在了；而User Data是通过在第一次启动实例的时候执行配置的命令或脚本进行安装和配置。

当然也可以同时使用User Data，对于一些动态的或者一些无法提前部署的配置或环境，做一些细微的调整和部署，进行快速的配置。

启动模板或者启动配置

对于使用AutoScaling组的业务场景，启动模板或者启动配置都可以基于之前创建的AMI，这样的话在实例弹性扩展时，通过之前创建的AMI启动的实例预置了业务需要的环境，可以直接快速上线。

CodeDeploy

CodeDeploy，用于将我们创建的应用程序部署至AWS。注意CodeDeploy不是部署AMI的服务，是用于将我们的应用程序部署至AWS，CodeDeploy支持：

• EC2的in-place就地部署/更新；
• AutoScaling组的in-place就地部署/更新；
• 通过蓝/绿部署创建新的AutoScaling组部署/更新；
• 支持Lambda函数的Traffic Shifting部署；
• 以及支持ECS的新任务集的Traffic Shifting部署

以上这些我们在CodeDeploy课时都详细的讲过，要弄清楚这些是如何工作的，认证考试中会有相应的考点。

OK，我们继续。

Elastic Beanstalk

Elastic Beanstalk，非常适合于中小组织刚接触aws，计划将业务从本地数据中心迁移至AWS的场景。

Elastic Beanstalk如何部署应用程序，部署的策略我们也在前面的Elastic Beanstalk的课时详细讲过了，共有4种部署策略：

• 一次性部署全部，同时将应用程序部署到全部的实例，这种策略会停止应用程序部署后在开启。
• 滚动部署以及附加批次滚动部署。是按批次分批进行部署，区别主要是在部署过程中是否启动额外的实例配合部署；
• 不可变部署，会启动新的实例完成部署任务；
• 以及蓝绿部署，会创建新的堆栈进行部署任务，然后通过Route53的加权记录将流量从旧的堆栈转移到新的堆栈。

OpsWorks

好，OpsWorks，如果您的组织已经在本地使用Chef或者Puppet，现在想迁移到云上，那么AWS OpsWorks就会非常适合这个场景，因为OpsWorks是Chef和Puppet server在AWS上的托管服务

OpsWorks可以管理EC2实例以及ELB，它不负责管理AutoScaling组。

Lambda函数

然后对于Lambda函数,可以通过Serverless Application Model，SAM，利用其拓展的CloudFormation和CodeDeploy,通过流量转移功能来进行Lambda函数的部署。

好的，以上就是我们今天的课时内容，我们对AWS的部署方式做一个对比和总结，这些内容包括部署的策略具体的流程，在认证考试中会出现相应的考点，如果还未掌握的同学需要复习一下前面的课时。

好，我们今天就到这里，希望能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

Hello大家好，我们今天的课时的内容是Serverless Application Model，SAM。

SAM功能和用途

SAM，无服务器应用模型，是用于在AWS上构建无服务器应用程序的一个框架，这些无服务器应用程序通常包括：Lambda函数，DynamoDB table，API网关等。

所有的配置都是通过YAML代码的，看起来有一点像CloudFormation。因为SAM是CloudFormation的扩展，是基于CloudFormation工作的。

比如：

• 创建Lambda函数，可以通过AWS::Serverless::Function；
• DynamoDB table，通过AWS::Serverless::SimpleTable；
• API网关，通过AWS::Serverless::Api；
• 以及Cognito User Pools。

SAM可以帮助您在您本地运行Lambda函数，DynamoDB table以及API网关，这样的话在部署之前可以在本地调试无服务器应用程序。

当您使用SAM开始部署应用程序时，它使用CodeDeploy来部署Lambda函数，使用Traffic shifting流量转移的特性来部署，这个我们前面的课时讲过。

SAM在后端是依赖于CloudFormation的，它是CloudFormation的扩展，因此拥有CloudFormation的可靠部署的特性，在SAM模板中使用CloudFormation来定义资源。这也是为什么当部署无服务器应用程序时，SAM是一个非常受欢迎的框架。

SAM的CICD架构

好的，要参加认证考试还需要了解SAM的CICD架构，我们一起来看一下。

首先，配置一个CodePipeline，CodePipeline是持续集成持续部署服务，可以实现快速、可靠的应用程序和基础设施更新。

您的代码存储在CodeCommit，然后发送到CodeBuild进行对代码进行构建、测试以及打包。

接下来会通过SAM的模板来声明和配置应用程序组件。然后比如我们要部署一个Lambda函数，SAM就会调用CodeDeploy来部署，并使用Traffic shifting流量转移的特性，在您的V1和V2版本间切换流量。

当然，也同样可以通过CloudFormation来部署和更新API网关以及DynamoDB table，这些通过CloudFormation都可以搞定，不过对于认证考试，一定要记住的是在使用SAM部署Lambda函数时，是通过CodeDeploy服务部署并通过Traffic shifting来切换流量的。

好的，以上就是今天的内容，比较简短，但是对于认证考试涉及的SAM的知识点来说应该是足够了，希望能给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

Hello大家好，我们今天的课时的内容是AWS Service Catalog 。

AWS Service Catalog服务对于新的AWS使用者比较友好，当一个AWS新手需要创建资源时，往往需要面对很多选项，比如相对于EC2，要选择AMI，实例大小等等，在这个时候往往这个用户就蒙了，只能遵循自己的内心去选择了（笑脸）。结果就会导致创建的资源不符合组织的标准，不符合组织的标准化要求，甚至有可能出现其他如安全等问题。

通过 Service Catalog，就可以为这类用户提供一个自助服务门户集中启动的资源，这些资源是通过 Service Catalog服务中的Portfolios，即产品组合来启动的。产品组合由产品及配置信息组成，是由管理员预先定义的，比如虚拟机，数据库，一些存储资源如EFS，等等。

也就是说，我们可以把预先定义好的、满足合规性、标准化要求的资源，作为Portfolios放到一个门户上，然后提供给使用者集中部署资源，因为资源是由管理员预先定义好的，通过这种方式就可以实现组织的一致性的监管和满足合规性要求；使用者也无需配置一大堆的选项，从而可以快速启动资源。

举个简单的例子，在很多组织中，研发部门可能都要启动一些AWS资源来进行内部测试，如果不同的研发人员都去启动EC2实例，然后选择AMI，选择实例类型等等，那么最终的资源的规格肯定是五花八门，肯定有用Centos的，有用Ubuntu的，还有同一系统不同的版本情况，以及不同的实例大小等等。这样对于组织后续的管理将会带来很大的麻烦，无法进行一致性的监管，也无法满足合规性要求，甚至可能会自行选择一些配置比较高而用不到或需要使用付费的实例用于测试，这样还会导致成本浪费。

所以Service Catalog服务，就可以解决这些问题。通过预先定义好允许启动的资源，做好相应的配置，放到一个集中的地方提供给研发进行快速启动和使用。这样的话，研发同学只要页面点击几次就可以进行部署，而且也可以遵循组织的一致性标准。

Service Catalog 管理员及用户流程

那Service Catalog 是如何工作的呢？它底层是依赖于CloudFormation的。

首先，对于Service Catalog，有两种用户类型，管理员以及最终的用户，也就是使用者。

管理员需要定义Product产品，那什么是Service Catalog的产品？

产品实际上就是由一个管理员定义的CloudFormation模板。管理员需要擅长编写CloudFormation模板，然后将这些和配置信息放到一起，就形成了一个Portfolios，我们就叫他产品组合吧。所以产品组合就是产品以及配置信息的一个集合。

然后每一个产品可分配IAM角色，当用户启动已分配有 IAM 角色的产品时，AWS Service Catalog 将使用该角色通过 AWS CloudFormation 启动此产品的云资源，这种方式叫作添加启动约束。

好，这样的话管理员创建的产品组合就可以在 Service Catalog 门户提供给最终用户启动。

然后讨论最终用户，也就是使用者。

向用户授予产品组合的访问权限，让用户能够浏览该产品组合并启动其中的产品。

然后这些用户，比如想要启动EC2实例堆栈，他们就可以在Service Catalog控制台启动这个产品。而产品是对应CloudFormation模板的，所以就会启动CloudFormation模板中预先配置好的资源，最终提供供应的产品，而这些产品已经经过适当的配置，适当的标记且准备好投入使用了。

在这个流程中，最终用户需要授予产品组合的访问权限，即访问产品组合以及Service Catalog控制台的权限；

用户是不需要被分配启动CloudFormation模板的IAM权限的。上面也提到过，可以通过给对应的产品添加启动约束。指定一个IAM角色，然后将各种需要的cloudformation权限，以及需要的EC2,S3权限都添加到这个角色中。最终用户启动产品时AWS Service Catalog 将代入此角色，这样做的好处是不用给最终用户太多太大的权限就可以启动Service Catalog中的产品，可以确保最终用户具有最低IAM权限，这是IAM的最佳实践，前面课程也讲过，分配权限要基于最小权限原则。

Service Catalog理论

好，我们继续Service Catalog理论的内容。

IT管理员在AWS上可以创建、管理和向最终用户发布已批准的产品组合。

每一个产品Product都是一个CloudFormation模板。利用CloudFormation模板可以做的事情就非常的多了，如创建虚机镜像，服务器，软件，数据库，区域，IP地址范围等等。

使用CloudFormation可以确保部署的一致性，实现组织标准化管理。

在前面的流程中，我们没有给最终用户使用CloudFormation的权限，而是只给了使用Service Catalog的权限，然后通过Service Catalog产品来调用后端的CloudFormation模板实现用户的需求。通过将产品添加到产品组合，并进行相应的配置后，最终用户，比如组织的某个部门的人员，就可以自助服务启动相应的产品。

所有的这些产品都是通过Service Catalog集中管理的。

为什么这么做呢，可以帮助我们的组织实现资源的一致性监管、满足合规性要求等等。

对于认证考试来讲，当有题目的场景是用户没有太多的AWS相关的知识或者不了解所有的启动时的配置选项，但是想要启动资源时，就非常适合使用Service Catalog。提前定义好CloudFormation模板，确保让用户只能做你想让他们做的事情，创建好产品，使用标签、配置等等实现标准化，最终提供给用户使用。

最后，Service Catalog 可与自助服务门户集成，如 ServiceNow，这样的话您就可以实现让最终的用户通过组织的ServiceNow门户来启动预先批准的AWS 产品。

好的，以上就是Service Catalog所有的内容，要记住使用Service Catalog的场景，希望本课时能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

Hello大家好，我们今天的课时的内容是AWS CodeDeploy。

AWS CodeDeploy在DevOps PRO认证考试中的考点比较多，在SAP认证考试您需要掌握使用CodeDeploy，将应用程序部署至EC2、ASG、ECS和Lambda的流程，这也是本课时所要讨论的内容。

AWS CodeDeploy

CodeDeploy 是一种部署服务，可以帮助如开发人员将应用程序自动化部署到实例，并根据需求更新应用程序版本。

比如我们有很多EC2实例，目前都在运行应用程序的V1版本，我们可以通过部署新的版本的代码将它们更新至V2版本。

注意这些EC2实例不是通过Elasitc Beantalk来管理的，而是使用CodeDeploy Agent，通过CodeDeploy Agent部署以及更新应用程序版本。

有很多开源的工具可以在AWS上完成部署任务，如：Ansible，Terraform，Chef，Puppet以及Elasitc Beantalk等等，也同样可以使用我们这个课时讨论的CodeDeploy这个AWS的托管服务，在AWS上进行部署任务。

那使用CodeDeploy有什么优势呢？它原生就与EC2 ，Auto Scaling Group ，ECS以及 Lambda进行了很好的集成。

所以接下来让我们深入了解下CodeDeploy如何部署代码到这些计算资源。

使用CodeDeploy 部署EC2

首先是使用CodeDeploy 部署 EC2实例，可以通过一个名为AppSpec.yml文件以及部署配置，来定义如何在EC2实例上部署我们的应用程序。

部署配置可以配置是一次性部署所有实例AllAtOnce，还是对所有实例进行分批逐步部署。

可以使用in-place就地部署，就地部署不会创建新的实例而是在原来的EC2实例上进行部署。

在每个部署阶段后，我们都可以在EC2上定义hooks验证部署是否有效。

除了一次性部署所有实例AllAtOnce这种方式，另外一个部署配置为HalfAtATime，也就是一次部署一半数量。我们看一下HalfAtATime这个部署流程：

假设我们有4台EC2实例，运行着V1版本，HalfAtATime首先会将其中的一半也就是两台EC2实例先离线，只保留两台运行V1版本的实例提供服务，也就是保留的这两台实例需要暂时承担所有业务的负载；

然后将先离线的两台实例更新至V2版本，目前4台实例，两台实例运行V2版本，两台实例运行V1版本。然后同样，将之前未更新的两台V1版本实例离线，然后升级至V2版本。

这样就通过HalfAtATime，每次部署一半数量的实例，通过CodeDeploy将四台实例全部部署至V2版本。

好，**除此之外还有一个OneAtATime部署配置，每次只部署到一个实例，**这些都是CodeDeploy将代码部署至EC2的不同的部署配置，我们重点掌握上面的这个每次部署一半数量的实例的整个流程。

在本例中使用的是in-place也就是就地部署，运行V1版本的实例需要先离线，然后进行部署，更新至V2版本提供服务。

使用CodeDeploy 部署ASG内实例

好的，接下来讨论使用CodeDeploy 部署 Auto Scaling Group中的EC2实例。

部署ASG中的实例有两种方式，第一种是in-place也就是就地部署，直接更新当前ASG中所有的EC2实例，ASG的就地部署和上一张PPT中介绍的EC2的就地部署几乎是相同的。

另外由ASG新创建的EC2实例也会进行自动化的部署。如果在CodeDeploy部署期间，您的ASG进行了横向扩展创建了新的EC2实例，CodeDeploy也会将应用程序部署至这些新的实例。

好，这是in-place也就是就地部署。

还有一种部署类型为蓝/绿部署，在这种情况下会根据之前的配置创建一个新的 Auto Scaling Group部署应用程序新版本，然后会将现有业务流量切换到新的 Auto Scaling Group内的实例。可以配置部署完成后如何处理旧的实例。蓝/绿部署必须要使用ELB。

我们来看下部署流程：这里有个ALB在提供服务，然后下面挂着一个 Auto Scaling Group。CodeDeploy可以将您的应用程序部署到ASG中的EC2实例，假设目前我们已经在ASG内启动的EC2实例上部署了应用程序为V1版本；即使当这个Auto Scaling Group扩展启动了新的EC2实例，CodeDeploy也是足够的智能，能够将应用程序部署到新启动的实例上。

假设我们现在需要使用蓝/绿部署将V2版本部署到实例并提供服务，那么CodeDeploy会创建一个新的 Auto Scaling Group及在组内根据配置启动新的实例用于部署，然后CodeDeploy会将新的ASG内的实例部署至V2版本。这时V1版本和V2版本的ASG同时存在；然后如果一切顺利的话，V2版本的ASG的EC2实例开始向ELB注册，流量开始路由到这些新的V2版本的实例。最终原始环境中的V1实例将取消注册，并根据部署配置进行处理：要么终止，要么继续运行。到现在整个蓝/绿部署完成。

好，从使用蓝/绿部署 部署ASG实例的整个流程中可以了解到，蓝/绿部署将启动新的实例，并在新的实例部署新版本的应用程序，之后在完成流量切换对外提供新版本服务；而前面的in-place也就是就地部署，是在同一个实例上进行部署，就是在原实例上先停止服务，然后在同一实例部署新版本并提供服务，至于具体使用哪种部署方式需要根据您自身的需求。

使用CodeDeploy 部署Lambda

好的，接下来讨论使用CodeDeploy 部署 Lambda。

CodeDeploy支持用来部署Lambda函数，部署Lambda函数时支持Traffic Shifting ，即流量转移功能，可以通过配置Lambda的别名指定两个不同的Lambda函数版本，并可以配置两个函数路由流量的比例。

同样可以定义hooks，通过配置一个函数用于在部署Lambda函数时，在流量转移前及流量转移后的验证和测试。

您可以设置一个CloudWatch Alarms，可非常容易的实现自动回滚动作。

最后，如果您使用的是AWS Serverless Application   ,SAM，那么您通过SAM部署新的Lambda版本时，SAM原生使用CodeDeploy来进行部署，要记住这一点。

我们看一下具体的流程：

目前有一个Lambda别名，运行着V1版本的Lambda函数；然后假设我们的CI/CD系统触发了CodeDeploy，CodeDeploy在同一Lambda别名部署Lambda函数的V2版本，注意在目前的阶段Lambda函数的V2版本还没有流量。

然后，如果我们配置了流量转移前的hook，CodeDeploy就会先运行它，这个hook是配置的另外的一个Lambda函数，作用是测试V2的Lambda函数是否运行正常，也被称为Pre-Traffic Hook。

如果V2函数能够正常工作并通过测试，那么CodeDeploy将使用Lambda别名的Traffic Shifting ，流量转移功能，开始在V1和V2版本的函数之间转移流量，然后从现在开始V2版本函数开始接收流量。

您也可以配置一个CloudWatch Alarms来监控您的Lambda函数的各种指标，可以实现如果触发CloudWatch Alarms，然后CodeDeploy自动回滚之前的部署，将环境回滚至Lambda函数的V1版本。

最后，如果Traffic  Shifting流量转移完成，流量全部转移至V2版本的函数后，还会运行一个Post-Traffic的Hook，也就是流量转移后的Hook，是您定义的另外的一个Lambda函数，它的作用是当流量转移至V2函数后，做一些测试确认。

如果一切顺利，V1版本的函数就完成使命了，Lambda别名中V2的Lambda函数接收流量提供服务。

好的，这就是使用CodeDeploy 部署 Lambda的一些关键的知识点，我们要了解Lambda别名的Traffic Shifting 流量转移功能 ，以及Pre-Traffic Hook 和 Post-Traffice Hook，这两个用于在部署Lambda函数的  流量转移前 及 流量转移后 测试部署的Lambda函数。

使用CodeDeploy 部署ECS

最后，使用CodeDeploy 部署 ECS。

对于ECS和Fargate，同样支持蓝/绿部署，要注意这些相关的配置是在ECS服务进行配置，而不是在CodeDeploy的控制台。

部署方式大致和前面介绍的服务是一样的，先创建一个新的任务集，然后将流量路由至新任务集。

在部署完成后，CodeDeploy将检查在一定的时间内新部署是否稳定。然后如果一切顺利，旧的任务集将会被终止。就是说如果您需要，可以预留一些时间观察/发现问题。

同样，我们看下整个的流程：

前端会配置一个应用程序负载均衡器，ECS服务挂在ALB下面。

ECS服务启动了一个ECS任务—ECS任务定义1，然后 CodeDeploy开始蓝/绿部署，也将会使用流量转移功能，ECS服务会启动过一个新的任务集，任务定义2，并挂到ALB下。然后CodeDeploy开始进行流量转移，下面的这个截图是CodeDeploy的截图，可以看到流量转移正在进行，原始的实例目前有60%的流量，而替换的实例有40%的流量，随着时间的推移流量转移将会逐渐完成。然后CodeDeploy将检查在一定的时间内新部署是否稳定，如果一切顺利，旧的任务集、ECS任务定义1将会被终止，CodeDeploy成功部署了ECS，整个流程结束。

好的，通过以上内容，可以了解到通过CodeDeploy来对几个计算资源进行部署时，他们的大致的流程基本是一样的。只是每个服务有各自的一些功能特性，而CodeDeploy也是利用这些服务的特性来完成部署以及切换流量等任务。对于参加SAP认证考试，将这4种资源的部署流程搞清楚基本就差不多了。

好的，以上就是CodeDeploy所有的内容，希望本课时能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

Hello大家好，我们今天的课时讨论AWS Systems Manager ，SSM。

SSM是AWS比较强大的一个服务，在AWS的DevOps以及SysOps认证考试中考点非常多，在SAP认证考试同样也会涉及一些SSM的考点，我们通过这个课时争取把这些考点都搞定。

AWS Systems Manager 概述

• 可以使用 SSM 来组织、监控 AWS 资源并对其自动执行管理任务，SSM可以帮助我们管理大规模的EC2实例以及本地的服务器。
• 它提供了管理基础架构的运营洞察力，将需要管理的资源进行标记后，可以在SSM中查看整合的信息，能够帮助我们很容易的提前发现问题所在。
• 如果您需要为很多EC2实例打系统补丁，就可以使用SSM来做，这部分的内容在SAP认证考试中会出现，我们在后面也会详细的讨论，您需要记住所有相关的步骤。
• SSM支持WINDOWS和LINUX操作系统，并与多个AWS服务集成，如CloudWatch指标和仪表盘，以及AWS config，通过它跟踪EC2实例的配置，等等。
• SSM的大部分功能是免费的，部分功能需要付费。

AWS Systems Manager 功能

好，下面我们就深入了解下SSM提供的功能，包括运营管理、应用程序管理、执行和变更以及实例和节点四大部分，每个部分都提供了多个服务。

运营管理，提供了一系列的服务帮助管理AWS资源，包括：

• Explorer ，可以跨AWS区域显示您的AWS资源相关数据的聚合视图(OpsData和OpsItems)。
• OpsCenter，可以聚合多个AWS服务中的事件集中查看和管理，降低解决问题的平均时间。
• CloudWatch仪表盘以及PHD仪表盘。

应用程序管理，包括：

• 资源组，提供了查找和分组AWS资源的功能，可以查看整组资源的分析报告以及可对资源组的资源运行复杂的任务。
• Appconfig，提供了应用程序配置管理和部署。
• 参数仓库，Parameter Store，用于集中管理密钥和配置数据等，将敏感数据与代码和配置分离。

执行和变更，包括：

• 自动化，可以简化常规的任务，将常见的IT任务定义成SSM文档的一系列步骤，并对资源大规模执行这些步骤。如自动关闭EC2实例或自动创建AMI等。
• 变更日历，可以通过制定一个时间范围，允许或者阻止在指定时间范围内对AWS资源执行变更。
• 可以通过创建维护窗口，为大批量实例安排并实施常规任务。如给实例打补丁、执行自动化任务，或在指定期间执行其他可能中断性任务。

然后，实例和节点，包括：

• 合规性，配置并监控管理的EC2实例的的补丁安装和状态管理器配置合规性数据，集中管理合规性，修复合规性问题。
• 清单，Inventory，提供了收集管理实例的元数据，如已安装应用程序，网络配置，更新包等
• 托管实例及混合激活，提供混合云和跨云的管理，将这些资源安装和激活SSM相关的功能等
• 会话管理器，只需要一次点击就可以安全登陆实例，不需要开启SSH服务，且无需配置入站策略和管理堡垒机。
• 运行命令，Run Command，可以安全、批量的在您管理的EC2实例上运行命令而不需要ssh通道。
• 状态管理器，定义和维护操作系统或应用程序的配置，集中对配置进行管理。
• 补丁管理，Patch Manager自动化安装、修补系统补丁。
• 最后，Distributor用于打包自己的软件或查找AWS提供的软件并安装部署。

可以看到SSM提供了很多很多的功能，我们后面主要针对认证考试重点对Patch Manager，Parameter Store，Run Command和维护窗口的内容进行讨论，所以我们开始吧。

AWS Systems Manager 是如何工作的？

介绍完SSM的功能，那么首先我们要了解Systems Manager是如何工作的？

AWS提供了Systems Manager 服务，然后您还需要在您想要管理/控制的实例或服务器上安装SSM agent，SSM可以管理本地数据中心的服务器以及EC2实例。

在一些AMI中默认安装了SSM agent，如Amazon linux AMI 、Amazon linux 2 AMI  以及 一些Ubuntu的AMI。如果您的系统没有默认安装，就需要自行安装SSM agent。在本地的服务器或者EC2实例上安装了SSM agent后，SSM agent就会和SSM service进行通信并向SSM service进行注册。

那如果有某台实例无法通过SSM service进行管理，那么非常有可能是SSM agent的问题：要么是SSM agent的配置问题，要么就是在其管理的EC2实例上没有配置正确的允许SSM操作的IAM角色。

我们看一下这个图示，在需要管理的EC2实例或者本地的服务器上需要安装SSM agent，SSM agent需要和SSM service进行通信，所以我们还要给EC2实例定义并分配一个IAM角色，允许SSM agent 与 SSM service进行通信。

一旦我们所有的EC2实例和本地的服务器都正确的安装并配置了SSM agent，并可以正常和SSM服务进行通信后，就可以利用SSM服务提供的多个功能来对实例进行管理。

AWS Systems Manager – 运行命令

那么接下来我们就对前面提到的SSM的4个功能进行讨论。

首先，我们来讨论下运行命令（Run Command）。

Run Command可以安全、批量的在您管理的实例上运行命令而不需要配置ssh通道。

它可以在管理的实例运行document，一个脚本或者一个单独的命令。

可以将多个EC2实例分配为一个资源组，然后可以在一个资源组的多个实例上运行命令。

然后可以通过配置rate controls ，进行执行命令的并发配置以及错误控制。来控制运行命令的并发数量以及当执行命令的错误数量达到配置值时停止执行。

SSM与多个AWS服务进行了集成，比如IAM和CloudTrail，可以通过IAM控制使用SSM的用户权限，以及通过CloudTrail进行分析和审计，为SSM提供了审计以及安全的控制和保障。

Run Command是不需要实例开放SSH的，他不是通过SSH，而是通过安装在实例上的SSM Agent来执行命令。可以通过SSM服务的会话管理登陆实例，而不通过SSH。这样的话完全可以不依赖SSH服务，在某种程度上也提高了一些安全性。执行的结果的摘要也会显示在控制台中。

我们来看一下，有一台EC2实例，我们没有在实例上配置SSH服务，并已经将SSM Agent安装到了这台实例上，假定进行了正确的配置。然后SSM Agent将会和SSM服务保持通信。当我们在SSM上执行Run Command时，命令会被发送到SSM Agent，SSM Agent直接在EC2实例上执行相应的命令，在这个流程中并不需要实例配置SSH，并可以通过CloudTrail对SSM的所有API调用进行分析和审计。

SSM Patch Manager – patch baselines

好的，接下来的内容我们讨论下SSM的Patch Manager，它的用途是为管理的EC2实例批量、自动化的进行打补丁操作。

那么首先，您需要了解的是您需要定义一个补丁基准，也就是patch baselines。

patch baselines定义新补丁发布几天后自动批准补丁，以及批准安装和拒绝安装补丁的列表。

下面我们来看下由AWS预定义的patch baselines，这些patch baselines的命名需要大家记住。

先看LINUX系统：

AWS-AmazonLinux2DefaultPatchBaseline，这个是Amazon Linux 2 预定义的PatchBaseline。

以及其他的一些常见的Linux预定义的PatchBaseline，如：

AWS-CentOSDefaultPatchBaseline，AWS-RedHatDefaultPatchBaseline，AWS-UbuntuDefaultPatchBaseline，以及AWS-SuseDefaultPatchBaseline。

可以看到AWS预定义的patch baselines的命名有一定的规律，都是AWS-系统名称在加上DefaultPatchBaseline。

对于WINDOWS操作系统有一些不同，补丁会在释放7天后自动被批准。所以一旦windows补丁发布7天之后，将会自动被批准并将通过PatchBaseline进行打补丁。

对于WINDOWS操作系统，最重要的一个预定义的PatchBaseline是AWS-DefaultPatchBaseline ， 这个PatchBaseline的内容是将安装所有WINDOWS的关键更新和安全更新。

还有一个命名为AWS-WindowsPredefinedPatchBaseline-OS的PatchBaseline，它的内容和上面这个是一样的，都是安装WINDOWS的关键更新和安全更新。

然后，AWS-WindowsPredefinedPatchBaseline-OS-Applications，这个PatchBaseline除了会更新关键更新和安全更新，还会更新您的EC2实例上的windows应用程序。

要参加认证考试，要记住上面这些由AWS预定义的PatchBaseline的名称，尤其是这个AWS预定义的windows 的AWS-DefaultPatchBaseline。

另外，除了使用AWS预定义的，也可以自定义PatchBaseline，定义要自动批准的补丁，如定义自动批准补丁的操作系统的名称，定义更新的类别，如关键更新，还是安全更新等，以及严重程度如关键、重要等等。

总之，一旦确定了PatchBaseline，接下来的步骤就是要定义如何将这些补丁应用到windows或linux系统。

SSM Patch Manager – 步骤

对于参加认证考试，需要记住SSM Patch Manager的所有步骤，我们一起来看一下

1. 第一步是定义PatchBaseline，这个前面我们讨论了。如果您有多个环境如多个不同版本的Linux或者同时使用Windows和Linux，那么您可以定义多个PatchBaseline。
2. 第二步是要定义修补补丁组， patch group。patch group就是使用标签将实例进行分组管理，比如按照环境来区分的话，有开发环境、测试环境、生产环境，我们可以定义不同的 patch group来对不同的环境的实例进行管理。
3. 然后第三步是定义一个维护窗口，maintenance window。通过维护窗口，您可以定义一个时间表，以定义何时可以对实例进行可能的潜在破坏性的操作，如为系统打补丁、更新驱动等等。为了最大程度地减少对您的服务可用性的影响，建议配置维护窗口，并将对实例打系统补丁的操作安排在维护窗口进行，以在不中断业务运营的情况下进行打补丁操作。
4. 第四步，我们必须定义在维护窗口需要做什么。首先需要创建一个维护窗口任务，指定一个run command名为 AWS-RunPatchBaseline 的document。它是跨平台的，可以支持windows和linux操作系统；
5. 然后通过配置任务的rate controls ，进行执行命令的并发配置以及错误控制。
6. 最后，我们可以使用SSM inventory定义和监控补丁的合规性。

以上就是完整的步骤，看起来有些复杂，概括起来就是通过以上这几步来通过SSM的Patch Manager批量打补丁。

1. 首先定义或者选择默认的PatchBaseline，定义打补丁的列表。
2. 然后创建patch group，将您需要批量打补丁的实例进行分组。
3. 定义一个维护窗口，在维护窗口指定一个名为AWS-RunPatchBaseline的document，大家需要牢记这个document的名称。
4. 补丁会在维护窗口按照任务配置的rate controls进行应用，也就是进行打补丁操作。
5. 最后，可以使用SSM inventory定义和监控补丁的合规性。

可以看下右侧这个图，这个图就是我们上面介绍的流程，希望能够帮助大家理解。

如果您仍然对这部分有疑问，可以访问图下方的AWS官方的博客，里面的内容应该会有所帮助。

对于SAP认证考试，您需要掌握上面这部分的内容，尤其是前面的这个在维护窗口指定的AWS-RunPatchBaseline的document的这个名称，以及前面讲过的windows操作系统aws预定义的PatchBaseline的具体的名称。

AWS Systems Manager – Parameter Store

好我们继续，接下来是Parameter Store。

Parameter Store为我们的配置数据以及密钥提供了一个安全的、分层的存储。您可以将您的密码，数据库字符串，AMI ID，或者license作为参数值存储到Parameter Store，然后可以通过脚本，命令或者SSM documents引用您存储的值。

这样的好处是您可以通过这种方式将您的代码和密钥等重要数据分离。

它可以使用KMS无缝的进行加密（可选）。

它是无服务器的，可扩展的，高度持久的，简单的SDK。

您可以对存储的配置数据以及密钥进行版本追踪。

所有的存储的参数的管理使用路径的方式，可以使用IAM策略来定义安全访问这些路径。

如果Parameter Store的内容变更可以通过CloudWatch Event收到通知。

它与CloudFormation集成，可以在CloudFormation模板中拉取在Parameter Store存储的密钥。

我们先看下存储/引用明文配置的情况，我们的应用程序要访问Parameter Store中存储的明文配置，在这种情况下Parameter Store将只检查应用程序的IAM权限信息，来确定明文的配置是否允许应用程序访问。

另一种情况是访问加密的配置，在这种情况下，如果IAM权限信息正确，SSM服务首先会访问KMS服务完成解密。

另外，可以使用SSM Parameter Store 的API从Secrets Manager取回密钥，这也是我们接下来要讨论的内容。

AWS Parameter Store – 分层结构

Parameter Store存储参数时支持层次结构，使得大规模的组织和管理参数更加的容易。

支持参数存储的层次结构，可让您根据部署来组织参数。它为组织参数，查询和权限控制提供了强大的支持。

我们通过一个例子来看下什么是层次结构存储。

比如我们可以定义部门为第一层，假设我们叫做my-department 。

然后是应用程序名称，如my-app。

应用程序的下一层我们可以定义开发环境dev，以及生产环境prod。

在环境的下一层我们定义实际存储的参数，比如db-url，用于存储DB的url的明文数据；以及db-password用于存储DB密码，您可能希望通过KMS进行加密的参数，生产环境参数同上所述。

好，然后在my-department下除了这个my-app，可能还会定义其他的应用，other-app，或者定义其他的部门other-department。

以上的例子就是一个常见的分层结构。

最终您可以通过调用这个指定的路径/aws/reference/secretsmanager/secret_ID_in_secrets_manager，从Secrets Manager取回密钥；或者我们也可以通过调用获得由AWS管理的参数，比如通过调用这个路径获得amazon linux的最新的AMI ID。

最后，如果我们部署了lambda函数，我们可以使用GetParameters 或者 GetParametersByPath API 基于我们前面分层结构的环境来获取对应的参数。基于环境，我们可以配置不同的lambda函数只允许访问对应环境的参数。

好的，以上就是SSM所有的内容，在前面尤其是强调过的重要内容需要大家掌握，希望本课时能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

Hello大家好，欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》，我们今天的课时讨论AWS OpsWorks的内容。

AWS OpsWorks的内容在 DevOps认证考试中占的比重会比较大，但是在SAP认证考试涉及的内容并不多，可能会有1，2个考点，争取通过这个课时覆盖OpsWorks的这些考点。

AWS OpsWorks

首先，大家要对Chef和Puppet 要有所了解，他们都是开源的配置管理工具，可以帮助我们部署、配置和管理服务器。

目前有很多组织都在本地数据中心使用Chef和Puppet来做配置管理，当然他们也可以运行在AWS云上管理 EC2实例。

所以如果您的组织已经在本地使用Chef或者Puppet，现在想迁移到云上，那么AWS OpsWorks就会非常适合这个场景，因为OpsWorks是Chef和Puppet server在AWS上的托管服务。

在运维自动化方面，OpsWorks所提供的功能的和AWS SSM服务有一些类似，但OpsWorks是基于Chef或Puppet这两个开源工具的。

所以对于认证考试，可以简单的理解如果您在本地使用Chef，然后想迁移上云，那么就非常适合使用OpsWorks；

如果您想迁移您目前使用的其他配置管理工具到OpsWorks，不是很推荐这么做，因为可能涉及很多工作。

因为OpsWorks和Beanstalk 或者SSM相比最大的优势是针对于如果本地已经在使用Chef或者Puppet，然后您想快速迁移您的应用程序到云上，这个场景就非常适合使用AWS OpsWorks。

Chef和Puppet的知识点

接下来我们快速过一下Chef和Puppet的知识点。

他们都是配置管理工具，可以实现配置即代码，帮助我们执行一致性部署任务。

Chef和Puppet可以运行在windows和linux操作系统。

使用Chef和Puppet可以实现的运维自动化的任务包括：用户账号管理、cron、ntp、包管理以及服务管理等等，这些是通过“Recipes”、“cookbooks”或者“manifests”来进行管理的。“Recipes”、“cookbooks”和“manifests”他们是Chef和Puppet的组成部分，所以，如果您看到这些关键字，请考虑使用Chef和Puppet以及OpsWorks的场景。

前面也提到了，Chef和Puppet 与AWS的其他管理服务，如SSM、Beanstalk和CloudFormation，实现功能有一些类似，但正如我前面所提到的，Chef和Puppet是开源的，他们是可以跨云工作的。

如果您的组织想要迁移至AWS，且想要使用Chef和Puppet 或者已经在本地使用他们进行配置管理，就可以考虑使用AWS OpsWorks。

AWS OpsWorks 堆栈

一个比较重要的知识点：AWS OpsWorks 堆栈，它是做什么的呢？

AWS OpsWorks Stacks 是一个服务，提供了一种用于创建和管理堆栈及应用程序的简单灵活的方式。

借助 AWS OpsWorks Stacks，您可以部署和监控堆栈中的应用程序。

那什么是堆栈呢？我们一般会把相同用途，在逻辑上要统一管理的EC2实例和AWS相关资源的集合称为堆栈。

比如我们的一个WEB应用程序通常需要应用程序服务器、数据库服务器、负载均衡器等，我们就可以把这些组成部分创建为一个堆栈，进行统一管理。

我们看一个架构，假设这个是我们的一个WEB应用程序，它包括了负载均衡器，一些跑应用实例以及数据库实例，我们就可以把这些资源创建成一个OpsWorks 堆栈。

每一个堆栈是由多个层组成，这就要了解层的概念，层代表一组提供特定服务的 EC2 实例，层是依靠 Chef 的Recipes来处理诸如在层中的实例上安装程序包、部署应用程序和运行脚本等任务。比如例子中的堆栈，有一个ELB层包括一个负载均衡器，ELB层属于服务层由OpsWorks进行管理。

然后我们可以看到有一个应用服务器层，包括多个实例。您可以将EC2实例添加到层，并通过OpsWorks来进行管理。OpsWorks支持多种启动实例的方式，比如全天候实例，或通过基于时间或基于负载自动启动和停止实例，但是要注意这些都是由OpsWorks管理的而不是由AutoScaling管理的。

可以配置cookbook和您的应用程序的存储库，然后通过OpsWorks Stacks非常重要的功能之一：生命周期事件，通过Chef的Recipes来处理如在实例上初始化环境，部署应用程序，运行脚本等任务等等。

比如配置应用程序层的setup Recipes，进行WEB服务器的初始化等任务；运行该层的Deploy Recipes将应用程序从存储库部署到该实例并执行相关任务等等。

最后，可以看到还有一个数据库层，可以使用RDS实例由OpsWorks来进行管理；也可以使用EC2自行搭建数据库服务，如果使用EC2实例，同样可以使用cookbook帮助我们管理这些实例。

好的，以上就是今天OpsWorks的内容，这部分内容在SAP认证考试中涉及考点不是很多，所以希望这些足够可以覆盖考点了，感谢大家的观看。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

CloudFormation是AWS的一个服务，借助CloudFormation，您可以创建一个描述您所需的所有AWS资源的模板，如EC2实例、VPC等等，然后CloudFormation负责为您完成创建和配置这些资源。

想要熟练使用CloudFormation需要大量的时间学习和实践，对于解决方案架构师认证考试，我们只需要了解CloudFormation是如何工作的，以及它提供的一些重要功能/特性，这也是我们这个课时讨论的侧重点。

CloudFormation，是AWS的基础架构即代码服务。可以理解成CloudFormation是管理云资源的服务，我们可以通过代码或者称为模板来创建和配置云资源。

通过将基础架构编写成代码的方式，您可以跨多个AWS账户，跨多个AWS区域，快速的部署或者复用您的基础架构，创建和配置AWS资源。

CloudFormation的优势概括起来主要有3点：

1. 简化基础设施管理
2. 快速复制基础设施
3. 轻松控制和跟踪基础设施层的变更

CloudFormation是一个较底层的服务，AWS的很多服务的执行都依赖于它，比如Elastic Beanstalk、Service Catalog以及无服务器应用模型框架等。

总得来说，如果您是开发人员，Sysops或者 Devops，CloudFormation是必须要掌握的服务；但对于架构师认证考试，我们只需要掌握CloudFormation的一些考点和功能即可，所以我们继续吧。

CloudFormation & ASG

我们先讨论下使用CloudFormation创建和配置AutoScaling组的一些重点内容。

首先我们要了解，当使用CloudFormation创建一个AutoScaling组时，CloudFormation只管理AutoScaling组的配置，它不负责管理组内的EC2实例，因为这些实例是通过AutoScaling组创建的。

您可以在CloudFormation模板中配置AutoScaling组的CreationPolicy 属性，定义收到成功信号的数量，这是什么意思呢，在创建堆栈时，AutoScaling组启动EC2实例，只有CloudFormation收到成功信号的数量达到配置的数量时，CloudFormation才将资源状态设置为“创建成功”，才会继续创建堆栈，这是通过CreationPolicy 属性来配置的。

如果想要通过CloudFormation更新AutoScaling组的EC2实例，需要创建并在CloudFormation模板中指定启动模板或启动配置，然后更新到该AutoScaling组；可以通过配置UpdatePolicy 属性，来定义AutoScaling组EC2实例的更新策略，也就是告诉AutoScaling如何进行EC2实例的更新，比如实例是滚动更新还是一次性更新等等。这是通过UpdatePolicy 属性来配置的。

我们举个例子，

有一个由CloudFormation管理的AutoScaling组，AutoScaling组中有2个实例-A1。
假设我们现在要更新AutoScaling组的EC2实例，首先，要创建一个启动模板或者启动配置，然后配置CloudFormation模板指定要使用启动模板或启动配置，以及配置UpdatePolicy。然后应用模板后，CloudFormation就会使用新的启动模板或配置，按照UpdatePolicy中指定的策略更新EC2实例，比如创建2个新的EC2实例，然后一切正常的话，AutoScaling组会删除之前的两个A1实例完成更新。

好的，以上是使用CloudFormation创建和配置AutoScaling组的一些重点内容，涉及到了CreationPolicy 属性 和 UpdatePolicy 属性的内容。

删除堆栈时保存数据

接下来我们讨论当CloudFormation堆栈删除时，如何保存/备份数据。

默认情况下，当删除堆栈时，CloudFormation将删除该资源并删除所有数据；而在有些场景下，我们希望在删除堆栈时，保留资源。在这个时候，就可以利用 DeletionPolicy 属性，您可以为要控制的每个资源指定 DeletionPolicy 属性，在某个资源的堆栈被删除时保留或 (在某些情况下) 备份该资源。

DeletionPolicy可以指定3个配置选项，我们一起来看一下：

首先，DeletionPolicy：Retain，可以向任何资源类型添加此删除策略。将DeletionPolicy：配置为Retain，这样的话CloudFormation 在其堆栈被删除时就会保留资源，而不删除资源或其内容。

所以，需要在删除堆栈时保留资源或数据就需要将DeletionPolicy配置为Retain。

第二个选项，DeletionPolicy：Snapshot ，也就是在删除资源前做个快照，这个配置只支持较少的资源。配置为Snapshot顾名思义就是在删除资源之前会为其创建快照，所以只有支持快照的资源才可以使用这个配置，比如：EC2的EBS卷、ElastiCache、RDS DBCluster、RDS DBInstance 以及Redshift Cluster等所有支持快照的资源，一般都支持配置为DeletionPolicy：Snapshot 。

最后一个选项，DeletionPolicy：Delete ，在堆栈删除过程中，AWS CloudFormation 将删除资源及其所有内容（如果适用）默认情况下，如果不指定 DeletionPolicy，AWS CloudFormation 将删除您的资源及数据。

但是有一些例外：

• 对于 AWS::RDS::DBCluster 资源，默认策略是 Snapshot。
• 对于 Amazon S3 存储桶，您必须删除存储桶中的所有对象才能成功完成删除。

从考试的角度来讲，要牢记，可以通过配置资源的DeletionPolicy属性，来控制当删除CloudFormation堆栈时资源和数据是否/如何保留。

CloudFormation & IAM

好的，接下来是CloudFormation执行的权限的内容。

当我们在创建/部署CloudFormation堆栈时，默认情况下，创建资源的权限和您使用的IAM用户的权限一致。IAM用户的权限决定了是否有创建资源的权限。也就是说假设您使用的IAM用户有创建RDS数据库的权限，那么当您部署CloudFormation堆栈时就会允许创建RDS数据库。

或者还有一种方式，是在创建堆栈时，通过指定CloudFormation服务角色，允许 AWS CloudFormation 代表您调用堆栈中的资源。通过分配角色权限，比如创建RDS权限，来控制CloudFormation执行操作的权限。

所以，当部署CloudFormation堆栈时，分配允许执行的权限有两个选择：
1、使用您的IAM用户的自身的权限
2、指定CloudFormation服务角色，然后分配角色权限，CloudFormation创建堆栈使用该角色的权限。

另外还有一点要注意，如果您想要通过CloudFormation创建IAM资源，如：创建IAM用户、IAM策略、IAM组等，需要显式确认模板可创建IAM资源。使用控制台时通过创建时勾选确认；使用CLI通过指定 –capabilities 参数的 CAPABILITY_IAM 或 CAPABILITY_NAMED_IAM。

显式确认的目的是提醒我们正在通过CloudFormation创建IAM资源，可能会通过模板给与高权限，需要仔细确认。

CloudFormation 自定义资源(Lambda)

CloudFormation可以使用Lambda自定义资源，扩展您的CloudFormation。
那什么情况下使用自定义资源呢？比如：

1. CloudFormation还没有支持的资源，如AWS新发布的服务。
2. 想通过CloudFormation管理非AWS资源，比如您本地数据中心的资源。
3. 或者执行一些和基础设施无关的动作，比如在删除前清空S3存储桶所有对象，或者实现创建堆栈期间动态查找AMI ID等等。
4. 以及自定义资源可以执行任何你想做的实现。

整个逻辑是这样的，我们梳理一下：

Lambda函数需要做什么，实现什么功能，这些逻辑是您负责实现的；然后将 Lambda 函数与自定义资源关联，则在CloudFormation创建、更新或删除自定义资源时就会调用该函数，执行您在函数中实现的逻辑，比如在本地数据中心创建资源等等。总的来说，你想实现一些目前CloudFormation没有很好支持的功能，就可以考虑通过自定义资源的方式。

CloudFormation的跨堆栈引用 与 嵌套堆栈

我们继续，CloudFormation的跨堆栈引用 与 嵌套堆栈。

要将资源输出从一个 AWS CloudFormation 堆栈导出到另一个堆栈，可以创建跨堆栈引用。

利用跨堆栈引用，您可以使用分层架构或面向服务的架构。可以在单独的堆栈中创建相关的 AWS 资源，然后将资源输出并在其他堆栈中引用，而不是在单个堆栈中包含所有资源；

例如，我们可以单独创建一个包括VPC、安全组和子网等资源的网络堆栈，然后将这些网络资源的值都进行输出，比如子网ID、安全组ID等等；然后单独创建一个Web 应用程序堆栈，引用前面创建的网络堆栈的输出创建堆栈资源，比如EC2实例等待

要创建跨堆栈引用，可使用 Export 输出字段标记要导出的资源输出的值。然后，使用 Fn::ImportValue 内部函数在其他堆栈导入该值。

采用创建多个堆栈分层管理架构，尤其是在组织中有很多堆栈时，这么做对于堆栈的操作会更加的灵活。

比如前面的例子，创建单独的网络堆栈，负责创建网络资源，输出子网、安全组ID等值；然后您的组织中的多个其他的堆栈，如应用程序堆栈，都可以直接导入这些值来创建应用程序资源，如EC2实例等。跨堆栈引用这种方式是AWS建议的最佳实践。

然后嵌套堆栈。

随着组织的发展，基础设施可能会越来越多，这样就可能会出现相同的资源在多个CloudFormation模板中都存在。

比如，同一个负载均衡器可能存在于多个模板中，您可以分离这些常见资源并为其创建专用模板，比如创建一个单独的负载均衡器模板，其他模板中的资源来引用此模板，也就是创建嵌套堆栈。

这样做有什么好处呢? 如果更新这个负载均衡器模板，引用该模板的任何堆栈将使用更新过的负载均衡器 (仅当您更新该堆栈后)。

举个例子，假如我们现在的应用程序堆栈是采用的嵌套堆栈，引用了单独创建的RDS和ELB堆栈模板；这样的话如果我们需要创建应用程序V2堆栈，需要使用相同的RDS和ELB资源，就可以直接引用RDS和ELB堆栈模板。而不是将RDS和ELB资源在每个需要的模板中都复制/粘贴一遍。

好的，以上是跨堆栈引用 和 嵌套堆栈的内容，总结一下，跨堆栈引用是多个堆栈都可以引用单个堆栈输出的资源，比如安全组ID；而嵌套堆栈，可以理解成类似于独立的模块，可以在多个堆栈中多次进行引用。

CloudFormation其他

好的，本课时的最后，来看一下在认证考试中可能会出现的CloudFormation的一些其他知识点。

首先是CloudFormer，CloudFormer 是一种模板创建工具，可从您的账户中的现有 AWS 资源创建 AWS CloudFormation 模板，比如您手动创建了一个EC2和安全组，您想生成一个包括这些资源的CloudFormation模板，那么就可以使用CloudFormer。

ChangeSets，更改集，当您需要更新堆栈时，在实施之前可以通过更改集了解您的更改会如何影响正在运行的资源，当您确认更改是您预期的情况后，可以执行更改集，然后 CloudFormation 才会对您的堆栈进行更改。

StackSets，堆栈集，使用堆栈集可以跨多个AWS账户和区域创建、更新或删除堆栈。如果您的组织是多账户环境，需要跨多个AWS账户和区域部署堆栈的话，堆栈集功能就会非常有帮助。

最后堆栈策略，使用堆栈策略可以防止堆栈资源在堆栈更新过程中被意外更新或删除。
堆栈策略是一个 JSON 文档，该文档定义可对指定资源执行的更新操作。比如您有一个RDS数据库存储重要的数据，那么您可以配置一个堆栈策略，保护你的RDS数据库。防止堆栈更新过程中您的RDS被意外更新或删除。

好的，这节课我们讨论了CloudFormation相关的内容，希望能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 如果您想获取本课程全部课时，请扫PPT的二维码加入。
• AWS爱好者的网址是www.iloveaws.cn，认证视频课程，免费的认证考试仿真题以及认证课程文章，都可以在网站找得到
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章。
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

我们开始今天的课程内容。

上节课我们实操演示了使用EB部署了一个示例应用程序，那如果之后需要更新EB上的应用程序时，就需要在EB对新版本的应用程序进行部署。

我们先来看下EB支持的部署策略，EB支持4种部署策略，分别为：
一次性部署全部，滚动部署，附加批次的滚动部署，以及不可变的部署。

我们需要了解每一种部署策略具体是什么，以及使用每种部署策略具体的场景。

一次部署全部策略

首先，一次部署全部策略，All at once。

假设我们现在有一个新版本的应用程序需要部署，“一次部署全部策略”表示将新版本同时部署到所有实例，比如我们现在EB的环境一共有两个实例，那么一次部署全部表示将新版本同时部署到这两个实例。

在执行部署时，环境中的所有实例将短时间禁用。所以一次部署全部策略，对于业务是有停机时间的。

当因为某些原因更新新版本应用程序失败时，只能通过手动重新部署之前的旧版本完成版本的回滚过程。

一次性部署，因为是一次性部署全部实例，所以所需的部署时间应该是4种策略中最短的；但是缺点是在部署的过程中，所有的实例会短时间内禁用，也就是说部署过程中您的WEB应用程序是无法对外提供服务的。

以上，是一次部署全部策略。

滚动部署

我们来看下第二种部署策略，滚动部署。

滚动部署，是将新版本的应用程序按批次、分批进行部署，批量部署新版本程序。

前面的“一次部署全部策略”，是将新版本同时部署到所有实例；而“滚动部署”，是在部署阶段对实例分批次进行部署,分批次禁用服务，然后部署新版本，在恢复禁用提供服务。

在滚动部署期间，一些实例通过旧版本的应用程序处理请求，而已完成批次中的实例通过新版本处理其他请求，就是说会有同时存在新老版本应用程序提供服务的情况。滚动部署不是将新版本同时部署到所有实例的，如果新版本的应用程序有问题，采用滚动部署策略并不会一下同时影响所有用户。

滚动部署有一个特点是，因为采用的是分批次进行部署，所以在部署过程中，您配置的实例总体容量将会减少。

什么意思呢？假设我们现在有3个实例对外提供服务，当采用滚动部署时，会将其中一个实例禁用服务，然后进行部署新版本应用程序，这样的话在部署过程中您提供服务的实例数量就由之前一共3个实例变为2个，提供服务的 总的容量减少了。

所以采用滚动部署策略，就需要关注应用程序的负载对于容量的需求，如果需要3个实例保障正常服务，采用了滚动部署策略，就可能会造成在部署过程中容量减少给应用程序造成性能问题，这一点要注意。

附加批次滚动部署

上述的问题，就有了第三种部署策略“附加批次滚动部署”，滚动部署的另一个版本。

“附加批次滚动部署” 同样也是批量部署新版本应用程序，但不同的是它会先启动新的额外的实例批次进行部署，以确保部署过程中应用程序能够使用完整容量。

比如我们现在在EB有3个实例，采用附加批次滚动部署新版本应用程序时，EB会额外启动新实例进行部署，应用程序始终保持在部署过程中有完整的容量可用。

在部署完成后，Elastic Beanstalk 将终止附加的实例批次。

不可变部署

第四个部署策略是不可变部署，Elastic Beanstalk 在您环境的负载均衡器后面创建临时 Auto Scaling 组以及新实例，然后将新版本的应用程序先部署到这个新的auto-scaling组的新的一组实例上。此实例和在之前配置中运行的原始 Auto Scaling 组中的所有实例一起，为流量提供服务。然后当部署完成后，当新的实例完成健康状况检查后，会将这些新的实例移动到旧的auto-scaling组，并终止临时的 Auto Scaling 组以及旧的实例。

执行不可变部署时，部署失败带来的影响是最低的，如果部署新版本的新的实例未通过运行状况检查，则 Elastic Beanstalk 将终止这些实例，删除新的auto-scaling组，并使原始实例保持不变提供服务。

所以，基于这些特性，采用不可变部署策略，是生产环境的核心业务的首选之一。

好，以上就是Elastic Beanstalk部署策略，这些内容对于考试非常的重要，会有涉及的一些考点，希望大家重点关注。

以上就是我们今天的内容，希望能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

AWS爱好者的网址是www.iloveaws.cn。
可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章
加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识
加入【AWS知识星球】持续学习。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

我们开始今天的课程。

上节课我们实操演示使用Elastic Beanstalk创建一个应用程序，这个应用程序是基于PHP平台，我们配置的是使其运行示例应用程序做演示，应用程序的名称为 iloveawscn-app。

查看创建的应用程序

可以通过访问EB管理控制台，环境左侧的“事件”，查看我们这个应用程序相关联的事件和通知。

通过事件的条目也可以看到当时创建 Web 服务器环境时，Elastic Beanstalk 创建一个EC2实例。

我们前面选择的PHP平台、以及webserver，还有示例应用代码都是运行在这台实例ID尾数为c8f0的EC2实例上。

通过EC2管理控制台，也可以查看到这台EC2实例，我们访问下EC2管理控制台。
可以看到实例id尾数为c8f0的这个实例，就是Elastic Beanstalk启动的实例。

您可以对这台实例完全控制，包括使用ssh登陆并管理这台实例，当然前提是您必须先创建 EC2 密钥对并配置 Elastic Beanstalk 的EC2 实例使用该 密钥对，然后才能访问EC2 实例。

按照Elastic Beanstalk的设计理念，通过Elastic Beanstalk的控制台页面，就能完成所有的管理需求，并不需要SSH登录到ec2实例。

接下来我们一起来看一下。

检索和下载日志

首先，当要对WEB应用程序进行故障排查时，最常用的方式是通过日志。通过查看Elastic Beanstalk 环境的 EC2 实例上的各类日志来对应用程序进行故障排查。

最常用日志文件有 Elastic Beanstalk 操作日志和来自 Web 服务器或应用程序服务器的日志，这些日志都会存储在EC2实例本地，而我们可以使用EB管理控制台轻松检索这些日志，而不必在通过SSH到实例上去查看。另外也支持将环境配置为将实例的日志实时传输到 Amazon CloudWatch Logs，然后通过CloudWatch检索日志。

那现在我们就来演示下通过EB控制台获取EC2实例的日志，EB控制台访问环境中的“日志”，然后请求“完整日志”。

好，现在就可以点击下载，下载日志到本地进行查看。

浏览器会下载一个ZIP文件，我们解压缩后进入到/var/log目录，可以看到里面有实例的messages日志，nginx日志，以及eb的各类日志等等。

通过EB控制台，不需要登录EC2实例，就可以非常方便将日志下载到本地，然后通过日志进行故障排查。

这是日志部分。

通过EB控制台部署新版本

另外我们可能需要定期更新、部署新版本的应用程序，将我们的更新的版本应用程序发布出去，通过Elastic Beanstalk控制台，操作起来也是非常的方便。

可以通过访问控制台，然后选择要更新应用程序的环境，然后通过这里的“上传和部署”，部署新版本的应用程序。

比如我们现在在本地更新了应用程序代码，需要打成zip包，然后点击“上传和部署”，选择本地的更新代码的ZIP文件，点击“部署”，然后Elastic Beanstalk会上传更新的应用程序，自动解压缩并放置EC2环境中正确的位置，自动重启必要的服务比如web server 、php等等工作，也就是说，所有更新、发布应用程序代码时需要的步骤，Elastic Beanstalk全部都自动帮我们搞定了，非常的方便。

这是应用程序更新和部署部分。

我们继续。

自定义环境（EC2数量、ASG、ELB、环境配等）

我们上节课的实操演示，在使用EB控制台创建应用程序时，采用的是默认的配置，默认的话只启动1台EC2实例的环境，所以我们刚刚也看到了目前我们的应用程序只跑在一台EC2实例上。

那如果后面应用程序的访问量上来了，一台实例不够了，我们是可以通过EB控制台，配置Auto Scaling 组，然后前面在配置一个负载均衡器，实现弹性伸缩和负载均衡，这些EB都是支持的。

我们看下具体在哪里配置。

选择要配置的环境，然后访问左边的“配置”选项卡，在这里提供了一系列选项，可以自定义环境中的资源以及 Elastic Beanstalk 行为和平台设置。

那我们现在要修改EC2的容量，实现弹性伸缩，就需要编辑“容量”这里，然后将“环境类型”由现在的“单一实例”，变更为“负载均衡”。配置最大，最小实例，使用实例的类型，AMI，实例放置的可用区，以及触发扩展的指标。

以及在这里可以配置基于时间的扩展，通过以上这些配置可以轻松的配置EB支持弹性伸缩和负载均衡。

我们在看下其他配置项，“软件”配置，基于我们现在演示的PHP环境，您可以配置PHP的内存限制，最长执行时间等重要的配置项，这些需要SSH到实例修改php.ini文件的工作都可以通过控制台这里进行配置。

我们在往下看，您可以通过这里的配置将实例的日志 流式传输到 CloudWatch Logs，然后在CloudWatch上对实例的日志进行检索和查看。

还有一些配置像实例的安全组，根卷的类型，以及前面提到的EC2使用的密钥对，监控相关的配置等等，这些都可以通过EB的控制台， 选择要配置的环境，通过配置页进行配置，可支持的配置项非常非常多，学友可以自己创建个环境，自己亲自实操一下更有助于这些知识的掌握。

好，以上就是我们今天的课程内容，希望通过这两个课时，能够让大家更了解Elastic Beanstalk。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

• 可以访问AWS爱好者的网址 www.iloveaws.cn，查看AWS认证资料、认证培训课时视频、仿真认证题库等
• 可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章
• 加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识
• 加入【AWS知识星球】持续学习

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。

我们开始今天的课程。

什么是Elastic Beanstalk？

Elastic Beanstalk 是AWS推出的一个能够快速上手易于使用的服务，它能够让开发人员更加轻松地在 AWS 云中快速部署和管理应用程序，甚至不熟悉AWS的用户也可以快速上手并使用该服务在 AWS 云中快速部署和管理应用程序。

作为使用者只需要上传应用程序，Elastic Beanstalk 将自动处理容量预配置、负载均衡、Auto Scaling 和应用程序运行状况监控的部署细节。使用者只需要上传应用程序，点击几次鼠标，几分钟内您的应用程序即可使用，无需您处理任何基础设施或资源配置工作。

Elastic Beanstalk 支持 Java、.NET、PHP、Node.js、Python、Ruby、Go 和 Docker Web 应用程序。

Elastic Beanstalk 不额外收费 – 您只需为存储和运行应用程序所需的 AWS 资源付费。

通过一个案例理解Elastic Beanstalk的优势

接下来我们通过一个简单的案例，来更好的理解什么是Elastic Beanstalk，以及它能够为我们做什么。

假设现在有一个简单的需求，需要在EC2实例部署一个WEB应用，且EC2的前端需要一个ELB来做负载均衡。
这是一个非常简单且常见的案例：WEB应用需要部署在EC2上，ELB用来给EC2做负载均衡

那传统的做法我们要实现这个需求，一般要以下几步：

1、启动一台EC2，在这个过程中还需要做一些安全组以及其他的一些配置。
2、然后需要登录EC2，安装webserver,比如nginx或者apache；还要对web应用的一些依赖项、环境进行安装和配置，比如你的应用是基于java的，就需要安装java环境；如果您的应用是基于php的，就需要安装php环境等等。
3、将您的web应用上传到ec2，放置到正确的指定目录，确认目录权限正确等等。
这些都搞定之后，
最后还需要创建一个ELB，配置健康检查，以及将其指向正确的EC2实例等等配置。

通过上面这4步配置，这个需求就基本上完成了，这是传统的方式。

以上这些步骤并不是说特别难，很多组织可能每天都在做这些工作。但是对于创业型公司或者一些小型组织，可能并没有设立运维或者解决方案架构师相关的岗位。当开发人员开发完web应用想要部署到AWS时，如果还需要开发人员来做以上这些步骤，毫无疑问搞定这些是需要要对AWS有一些基本了解的，对于开发人员来讲会具有一些挑战性，而且让开发人员把精力放在这些工作上面显然是不太科学的。

同样的这个需求，如果使用Elastic Beanstalk，实现起来就非常的容易，我们来看一下。

如果使用Elastic Beanstalk，只需要在Elastic Beanstalk控制台创建应用程序，选择应用需要的平台，上传您的应用代码就全搞定了，整个过程点击几次鼠标应用就可以完成部署及上线了，非常的方便。

这样的话使用Elastic Beanstalk，当开发人员开发完应用后，不用关心传统实现方式运行这些应用程序的基础设施的工作，Elastic Beanstalk会自动全部搞定，只需要几分钟，点击几次，就可以将应用部署到AWS并上线使用。

所以Elastic Beanstalk这个服务在小型公司，创业型公司非常受欢迎。

实操演示：使用Elastic Beanstalk部署一个WEB应用

接下来的内容我们就来进行一个实操演示，使用Elastic Beanstalk部署一个WEB应用，让大家更直观的理解Elastic Beanstalk相比于前面介绍的传统方式，部署一个web应用是多么的简单、容易。

我们开始吧！

使用浏览器访问Elastic Beanstalk管理控制台，然后点击“创建应用”。

应用程序名称，我们输入iloveawscn-app。

然后为应用选择运行的平台，支持.net/Go/Java/PHP等等。我们这个实操演示选择PHP，平台分支和平台版本保持默认，您可根据实际需求选择。

那当我们选择一个平台之后Elastic Beanstalk会在后台为我们做些什么呢？比如当我们选择PHP平台后，Elastic Beanstalk在后台启动一台EC2实例，然后自动为我们在EC2实例上安装好PHP的组件及环境等等工作，这些都是自动完成的。

选择平台后，下一步就是指定源代码来源，可以选择“上传代码”，从您的本地计算机上传源代码，或者从指定S3 URL从S3上复制源代码。

我们这节课选择“示例代码”做演示。选择“示例应用程序”，然后点击“创建应用程序”。

点击“创建应用程序”后，Elastic Beanstalk开始创建环境，会创建EC2实例，创建安全组，创建EIP，上传上一步指定的“示例代码”到EC2实例等等，这些都是Elastic Beanstalk自动配置的，我们不需要做任何事情。

在创建环境过程中，控制台将跟踪进度并显示事件，可以看到现在开始创建安全组，然后创建EIP，这个EIP会被分配到EC2实例使我们的应用可以在外网访问，然后创建EC2准备PHP环境等等，整个的过程大概需要5分钟，我们暂停一下视频。

好，大概等待了几分钟之后，我们的应用程序就创建好了，可以看到这里的运行状况是OK的。

在页面的上方，可以看到Elastic Beanstalk提供了一个URL，使用这个URL，就可以在公网访问我们的应用，对应我们前面的配置即为“示例代码”，我们访问下URL。

好，现在页面成功显示了“示例代码”。

整个部署应用的过程我们就点击鼠标操作了2，3步，Elastic Beanstalk就自动为我们把所有相关的事情都做好了，非常的简单和方便。

Elastic Beanstalk 为我们做了些什么？

接下来我们看下，我们这个部署需求，在我们点击“创建应用程序后”，Elastic Beanstalk自动为我们做了哪些具体的工作：

首先 创建安全组，创建一个EIP，然后会为我们启动一个EC2实例，并配置EC2的环境，如安装webserver ，PHP相关环境等等。

上面平台环境搞定后，会上传您的应用代码至EC2，我们的演示选的是示例文件，如果您前面的配置上传了您的代码在这一步将会将您上传的代码传至EC2，并对应相应的配置。最后，会为您的应用创建一个终端的节点，通过这个URL可以在外网访问您的应用。

以上这些就是Elastic Beanstalk自动在后台为我们做的工作，而我们要做的只需要再平台点击几次鼠标，即可完成应用的环境准备及部署。

这也是为什么很多开发人员喜欢使用Elastic Beanstalk的原因，因为不需要他们太关注基础设施的部分，开发完应用后只需要再平台上点击几次，就可以快速搞定上面这些事情，快速部署和发布应用。

好，以上就是我们今天的课程内容，我们今天介绍了Elastic Beanstalk基础知识，以及Elastic Beanstalk的优势，并使用Elastic Beanstalk进行了创建应用的实操演示，希望能够给大家带来帮助。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：

AWS爱好者的网址是www.iloveaws.cn。
可以通过扫码加入【AWS爱好者】微信公众号，查看原创的AWS知识点相关文章
加入【AWS爱好者】微信群，和其他同学一起备考，以及探讨交流AWS相关知识
加入【AWS知识星球】持续学习。

我们今天的视频课程就到这里，感谢大家的观看，我们下一课程再见。