AWS Infra系高级证书知识点整理(4)——运维、调度和其他工具篇 | 硅基生物的培养皿

type

status

date

slug

summary

tags

category

icon

password

⚠️

本文写作于 2025 年 6 月，截止到写作时间点为止，AWS考试体系高级部分分为SAP、DOP、ANS、SCS四部分。

本文将整理笔者自身备考除了MLS之外的高级考试过程中错过的题的关键点以及知识漏洞，供大家参考复习。

本文内容的正确性与非过时性都经过了Gemeni核查，但我无力随时更新这个总结，随着AWS技术本身的演进，其中的一些说法难免会和事实出现偏差，阅读时请注意这一点。

📝 运维工具

CloudFormation

<SAP> 当想要找关键词userdata的时候，如果选项里没提到userdata，第一反应应该是CloudFormation，因为它可以定义userdata

<SAP> CloudFormation StackSet可以在管理账户内定义模板，将代码部署到其他账户中，其他账户可以更新或删除这些infra，它还可以实现自动化，即新建账户时让StackSet中的infra自动部署

<DOP> 如果用户A编写的CloudFormation模板中开启了一台EC2，这个EC2拥有一个角色，那么如果用户B希望通过这个模板部署Stack的话，它的IAM Policy里就必须拥有"iam:PassRole"动作的权限，这样才能正确访问到用户A编写的模板里的角色

<DOP> CloudFormation堆栈更新失败并回滚失败时，可能是因为IAM权限不足以销毁资源，建议在更新权限后执行continue-update-rollback

<DOP> CloudFormation堆栈更新失败并回滚失败时，需要手动调整资源满足堆栈期望，并从控制台或CLI发出ContinueUpdateRollback命令

<DOP> CFN Set可以和SCP并用，一边给各个账户部署Config规则，另一边限制堆栈的删除（也可以允许账户管理员操作即允许堆栈漂移）

<DOP> 为了给OU各个账户中的CFN开启堆栈删除保护，可以创建一个新的CFN StackSet模板，部署Config规则检测是否启动了删除保护，并将修复操作添加到规则中

<DOP> EC2启动后，可以通过UserData脚本执行cfn-init以初始化实例配置，cfn-hup则定期（默认每15分钟）检查CFN中配置的EC2实例的Metadata块（如配置文件）的变化，并在检测到变化时重新运行cfn-init以应用新的配置。通过这个机制，可以更新AutoScaling组里机器上的内容而不触发重新扩容缩容

<SCS> CloudFormation使用【动态引用】语法来引用SecretManager中的DB凭证，来防止内容存储在模板里

<SCS> CloudFormation Guard使用一种基于规则的DSL在模板部署前验证合规性，例如它可以规定S3桶必须启用加密，否则会在验证阶段报错阻止不合规的模板提交

<SCS> CloudFormation通过堆栈策略禁用update:replace和update:delete以及开启堆栈删除保护，可以防止非管理员用户修改CF生成的资源

<SCS> 在CloudFormation中，推荐引用Secrets Manager的值保存敏感信息，比如密钥，使用Parameter Store存储环境变量等低敏感信息

<SAP> AWS Service Catalog的应用场景，是定义一套资源组合（比如使用CF），允许其他用户启动符合组织标准的一系列资源

Code系列

<SAP> Code Artifact是一个私有存储库，可以将PyPI等外部存储库加入其中，使得VPC内部的机器可以访问这个存储库，同时满足不能接入互联网的条件

<DOP> CodeArtifact使用S3做后端，因此需要S3网关终结点和CloudBuild子网路由表配置才能在没有互联网的情況下从VPC访问存储库，本质是私有子网访问S3的问题

<SAP> 可以使用EFS在多个Code Build项目之间共享大量的数据

<DOP> 实现CI提交即测试：通过EventBridge响应PR创建和更新事件，触发Lambda函数调用CodeBuild测试分支，并把结果作为评论写进PR里

<DOP> CodeBuild Report Group 是 CodeBuild 中用于收集、组织和展示构建报告的功能，可以将 JUnit XML 结果以可视化的方式展现出来

<SAP> AWS CodeCommit不能直接跨Region拷贝，只能通过Commit时触发Lambda函数间接拷贝

<SAP> CodeDeploy的Canary部署对两版本Lambda函数的流量切换指定、相比手动设置Alias权重的方式更为精确

<SAP> CodeDeploy可以直接读取Github上的REPO，这是通过webhooks实现的，不需要通过Lambda函数进行镜像

<SAP> 将CodeDeploy的Agent安装在AMI里之后，用这个AMI制作Auto Scaling Group的启动模板，将Code Deploy的Deploy Group关联到Auto Scaling Group，即可实现当代码发生修改时自动部署到新scale out的EC2上

<DOP> CodeDeploy部署组可以监控CW Alarm进行回滚

<DOP> 在使用CodeDeploy蓝绿部署ECS时，如果希望在流量转移之前对绿色版本进行测试和回滚，则可以在AfterAllowTestTraffic生命周期事件中调用Lambda函数，这个生命周期事件支持失败回滚

<DOP> 让CodeDeploy部署机房机器的方式是，让机器STS获取一个Role并通过cron定时更新凭据，安装CodeDeploy代理，向CodeDeploy注册本地服务器，并根据标签配置部署组

<DOP> CodeDeploy的一个最佳并行部署实践是，一个CodePipeline，对应一个CodeDeploy，对应多个并行执行的部署组

<DOP> CodeGuru Reviewer要和Code Commit关联，而不是Code Build

<DOP> 流程中批准下一个操作，批准日志要写入CloudTrail

<DOP> 如果需要监听dev/prod等每个分支的提交并触发pipeline，则需要在CodePipeline上为每个分支建立独立的Pipeline

<DOP> CodePipeline管道无法直接调用第三方API进行渗透测试，需要用Lambda函数间接调用

<DOP> CodePipeline可以在同一个pipeline中跨区域部署，前提是在目标区创建S3桶，并为CodePipeline配置适当权限。例如跨区域部署Lambda时，CodeBuild会将工件放在Region1的S3中，并构建CFN和Lambda，然后会自动将S3中的文件同步到Region2的S3，然后在Region2中构建第二套CFN和Lambda

<SAP> AWS CodeStar是整合了CodePipeline CodeCommit CodeBuild CodeDeploy等工具的工具，可以快速构建CI/CD Pipeline，快速开发简单的项目

Config

<DOP> 可以通过Config实时监控AWS资源配置的不合规性，并且发送到Security Hub自动集成不安全信息

<DOP> AWS Config通过Systems Manager自动化文档自动修复不合规的地方，如S3存储桶配置更改触发AWS Config检测是否允许了公共访问，并配置SSM来禁止

<DOP> 检测EC2是否贴了某个标签，是一个Config托管规则，无需自定义规则

<DOP> Config不能像SCP那样部署在一个账户上在多个账户中生效，必须部署在所有账户上（可以通过CFN StackSet批量部署），并通过一个管理账户中的AWS Config Aggregator收集所有情报

<ANS> Config可以保留当先系统所有设置的镜像，以便检查历史配置

<SCS> Config Rule可以在资源被创建时进行主动合规性评估，而无需等到资源建立后定时评估

<SCS> AWS Config可以捕获并记录许多AWS资源的配置更改，包括与区域资源相关的IAM策略附件或角色配置更改。然而，默认情况下，Config的客户管理配置记录器不记录全局IAM资源类型（如IAM用户、IAM组、IAM策略本身以及IAM角色本身）的配置更改。若要记录这些全局IAM资源的更改，需要用户显式地配置Config记录器以包含这些资源类型。

<SCS> IAM凭证报告有4小时的缓存，缓存会导致修改IAM密钥后生成报告后立刻生成的报告被Config显示资源不合规

<SCS> Config使用restrited-ssh规则可以检查安全组是否允许了无限制的SSH访问

System Manager

<SAP> Systems Manager中的Fleet Manager是可以访问windows远程桌面的

<DOP> 可以使用AWS Systems Manager自动化修复Amazon Inspector发现的安全问题，其中SM需要开启443端口

<DOP> Session Manager会话内容可记录到S3或CloudWatch Logs。CloudTrail记录Session Manager的API调用

<DOP> 使用SSM管理EC2，必须给EC2配置对应的角色调用Agent

<DOP> 可以通过 CW Alarm -> SNS -> Lambda -> SSM Run Command 的路径在EC2上执行脚本应对报警

<DOP> SSM的RunPatchBaseline支持在维护窗口期对windows和linux系统安装安全补丁

<SCS> SM Patch Manager既可以生成补丁报告，也可以安装补丁

<SCS> 使用Session Manager的条件是必须允许443访问，并且可以访问公网或拥有SM的VPC接口终结点

<SCS> Session Manager想访问私有子网里的EC2需要ec2message和ssm的VPC终结点，终结点的安全组需要允许443入站，EC2的安全组需要允许到终结点的443出站；如果需要使用Patch Manager，则还需要S3终结点

📝 调度工具

EventBridge

<SAP> 当一台EC2非预期宕机时，可以通过EventBridge监控AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULED事件，让SSM Automation自动重启EC2

<SAP> 自动扫描ECR镜像的功能由ECR（基础扫描）或与Amazon Inspector集成（增强扫描）提供。EventBridge是用于捕获这些扫描事件并发出通知的工具，例如触发Lambda函数发送自定义通知。

<SAP> 在微服务架构中，如果希望一个事件触发多个服务执行，EventBridge事件总线是更优的选择，因为它擅长事件路由、内容过滤以及与多个AWS服务和第三方应用的集成，适用于复杂的事件驱动架构。SQS更适合可靠的消息传递、高吞吐量异步处理和严格的消息排序（FIFO队列），在某些低延迟场景下甚至可能优于EventBridge，但其主要用途是解耦服务和缓冲消息，而非复杂的事件扇出路由

<DOP> CloudWatch 专注于性能监控、资源使用情况监控、阈值监控，EventBridge 专注于事件驱动架构，适合用于复杂的事件处理和跨服务的集成

<DOP> 可以通过EventBridge捕获CloudTrail里的特定记录，比如EC2创建事件，触发调用Lambda函数，给EC2打标签

Step Functions

<DOP> 可以用Step Functions检查多阶段部署中每个阶段是否成功，如果失败可以停止pipeline等待介入

<SAP> 当StepFunction发生异常时，处理方式是新增一个发Email用的SNS，建立一个通知SNS的Task，对所有节点增加Catch Field

<SAP> AWS StepFunction的Parallel可以应对所有参数都一样的并行处理，而每次都要传入不同的执行参数（比如Account ID）的话，需要使用Map

<SAP> Step Functions分为标准和快速（Express）两种工作流，后者功能虽然较少，但更适合于高并发工作负载，同时分为同步和异步工作流，前者会等待执行结束，可以进行重试和异常处理、获取返回值等，后者的状态需要从CW日志中获取

SQS

<SAP> SQS的DLQ只负责收集处理失败的消息，不负责自动再次处理（即便被Lambda函数retry了，那也不是SQS负责的范围，而是Lambda干的事），如果想对DLQ里的消息retry需要建立另外一个队列来消费DLQ里的消息

<DOP> 死信队列的Maximun Receives指的是消息被消费失败几次后放入死信队列，很多时候设置为1，一旦失败就立刻转入死信队列

<DOP> SQS接收到的消息数作为AutoScaling的指标并不合理，应该综合考虑囤积的消息数和EC2机器数量

📝 其他工具

其他工具

<SAP> AWS Amplify是快速制作前端重点网站的工具，可以直接集成API Gateway、Lambda、Cognito等，比如制作一个上传文件用的web界面就可以用它。（而EB则给出了更大的灵活性（配置文件）），适合全栈开发

<SAP> AppStream是桌面应用流，用于想把桌面应用交付给任何计算机而无需购买基础架构，即用浏览器的方式打开桌面应用，比如photoshop

<SAP> AppSync封装了一层GraphQL用来快捷访问数据库（可以类比API Gateway访问Lambda）

<SAP> AWS有个叫CART的网页版服务，能用调查问卷的方式帮你整理本地应用上云的初期应该做些什么

<SAP> CloudSearch是一个让用户不用在意全文检索引擎细节就可以实现全文检索的工具，适合快速低成本搭建系统，后续可以按需迁移至ES

<SAP> Amazon Connect的电话号码与特定的AWS区域和Connect实例绑定。当需要将电话号码从一个区域迁移到另一个区域时，这并非一个自动或同步的过程，需要提交AWS支持案例，并且在迁移过程中会产生停机时间。CloudFormation可以用于自动化Amazon Connect实例的复制和基础设施的预备，但电话号码本身的跨区域迁移是一个独立且需要人工干预的过程。

<SAP> Amazon Connect是呼叫中心服务，Amazon Pinpoint是信息发送/追踪服务

<SAP> Control Tower可以理解为是Organizations的扩展，用于快速创建符合最佳实践的多个AWS OU和Account，并且集成了单点登录（支持微软AD），还可以通过设置护栏禁止某些API操作

<SAP> Control Tower用来控制多账户的合规性（或是否符合最佳实践），并自动修复不合规的配置，用护栏阻止不合规的设定

<SAP> Compute Savings Plans比EC2 Instance Savings Plans具备更好的灵活度，支持EC2机型切换，适用于Lambda，适用于Fargate

<SAP> 当对两个账号设定Consolidated Billing之后，在账号A里买的RI可以在账号B里适用（只要AZ相同）

<SAP> Elastic Disaster Recovery通过Agent对机器进行实时Replication，保证在机器挂掉时以最快的速度切到备用机

<SAP> 如果要求的RPO相当短比如5分钟，最佳的EC2备份方案是使用EC2 Image Builder每5分钟在其他Region生成一个AMI，发生故障时使用CloudFormation启动这些AMI。相比之下AWS Backup本身并不专注于故障转移（存疑：这个方案能达到5分钟的RPO吗？）

<SAP> IoT Core是由规则引擎将数据写入其他AWS服务的，写入失败时首先检查这里

<SAP> Applicaiton Migration Service(MGN)是将本地虚拟机上的系统移植到EC2最便利的方法，且是增量生成AMI，过程还是加密的

<SAP> Migration Evaluator是利用公司的CMDB来分析上云成本的工具

<SAP> Migration Evaluator是一个无Agent的信息收集器，可以收集多台虚拟机上在跑着什么，进行评估迁移可行性、成本估算、风险估算、性能预测等，可以将输出的报告提供给Migration Hub进行可视化

<SAP> Migration Hub可以将需要上云的应用分组化、也可以推荐cost最合理的instance type

<SAP> AWS Application Discovery Agent 是在 AWS Migration Hub 下面管理的

<SAP> AWS Outposts是把机柜直接搬进数据中心的服务，在机柜里可以使用EC2、S3、RDS等常用服务，它主要用来实现例如数据必须保存在本地机房、要求极低的通信延迟性等需求。

<SAP> SES可以将邮件的基本信息发送至Firehose再发送至S3，让Athena分析

<SAP> 对电子邮件加密的方式是STARTTLS，使用SES发邮件需要将应用程序配置为使用STARTTLS 连接到SES，获取Amazon SES SMTP凭证，使用凭证通过SES进行身份验证

<SAP> 将FTP上到S3/EFS使用Transfer Family，它是夹在本地机器和S3/EFS之间到中间层，还可以结合EIP固定接收本地数据的IP地址

<DOP> Trusted Advisor适合检查 1.过小的资源消耗，如长期不用的EC2/RDS， 2. 接近服务限制的服务。通知与EventBridge集成

<DOP> Trusted Advisord可以识别泄露的IAM key，并触发EventBridge，从而触发Lambda函数删除IAM key，但它不是主动监测威胁的工具，本身也并不能直接触发Lambda函数

<SAP> VMware虚拟机迁移到EC2的方法是使用VMware vSphere客户端以OVF形式导出image，上传到S3，再用CLI执行EC2 import

<DOP> AWS X-Ray 守护程序是一个软件应用程序，它监听 UDP 端口 2000 上的流量，收集原始数据段数据并将其中继到 API。 AWS X-Ray 该守护程序与 AWS X-Ray SDK 配合使用，并且必须处于运行状态，这样 SDK 发送的数据才能到达 X-Ray 服务。

<SCS> SNS的De-identify（識別解除）策略可以将传入SNS的敏感数据masking化