AWS Infra系高级证书知识点整理(1)——计算资源与数据工具篇 | 硅基生物的培养皿

type

status

date

slug

summary

tags

category

icon

password

⚠️

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

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

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

📝 计算资源

EC2

<SAP> EC2 Instance Connect是Session Manager之外另一个可以不需要管理key pair就能SSH访问EC2的方法，便利性没有Session Manager高，相比于SM，它是一种不经过代理的直接SSH访问，用它访问EC2不需要key pair，每次都会生成临时的key pair，并且被Cloud Trail记录，要注意的是，它依旧需要开22端口

<SAP> Elastic Fabric Adapter (EFA) 是一种网络设备，可以将其附加到 Amazon EC2 实例以HPC和机器学习应用程序，与以前在基于云的HPC系统中使用的TCP传输相比，EFA提供更低且更一致的延迟和更高的吞吐量，它提高了实例间通信的性能，这对于扩展HPC和机器学习应用程序至关重要

<SAP> 一旦Amazon EC2实例启动，无法将其直接添加到现有的放置组中，放置组是实例启动时指定的属性，如果需要将现有实例纳入放置组，通常需要创建一个该实例的Amazon Machine Image (AMI)，然后从该AMI启动一个新的EC2实例，并在启动时将其指定到所需的放置组中，停止并重新启动实例并不能使其加入放置组

<SAP> 把EC2打包成AMI在其他region启动后，因为authorized_keys（公钥）也会被拷贝，所以用手头的pem文件（私钥）也可以访问这台新机器

<SAP> EC2 Dedicated Instances和Dedicated Hosts区别，前者说到底就是一机一实例，后者直接将物理机租给你随便开实例灵活度高，后者的Affinity模式还能保证机器和实例绑定，能解决服务上云时特定软件License必须绑定硬件并且能任意重启实例的需求，前者一个重要的问题在，不能确定到底启动的是哪台机器，所以不太适合拿来做需要和硬件绑定信息的软件的安装或测试，这时要选择后者

<SAP> AWS Compute Optimizer，是一个根据机器学习推定AWS资源使用是否合理的服务，帮助决策资源的使用是否合理

<SAP> AWS的RI根据是否提前支付分三种，能享受不同的折扣幅度，具体的使用场景时，当DB的流量峰值可以预见，需要开Read Replica节点时，可以使用没有预支付的方式来节约一部分费用，在峰值过后关掉节点，这样就能最大幅度低节约成本，而无需预先买断全年的RI

<DOP> StatusCheckFailed_Instance的问题源自EC2内部，StatusCheckFailed_System源自EC2外部比如网络和电源

<DOP> EC2发生维护 -> AWS Health -> EventBridge -> SNS

<ANS> ENA是EC2默认启动的加速机制，EFA多用于高性能计算，只有个别机器类型支持

<SCS> EC2的nitro类的实例支持和本地设备串口通信，是一个安全的分离环境，可以用于插入令牌设备

<SCS> EC2默认开启了源/目标检查，防止机器被截取用于非业务的流量中转，但是在作为NAT、VPN、透明代理等实例时需要关闭这个检查

<SCS> 禁止IMDSv1的方式是 Deny NumbericLessThan ec2:RoleDelivery 2.0

<SCS> 当EC2被发现有可疑活动时 1. 修改ACL断网停止攻击 2. 替换安全组为用于排查故障的安全组 3. 恢复ACL的修改恢复网络 4. 使用诊断工具启动新EC2，连接被攻击的EC2

AutoScaling

<DOP> 在CodeDeploy时如果发生EC2的scale out，则新机器上可能会被部署老版本的代码，避免这个问题的方式是部署时暂时关闭扩缩容

<DOP> EC2启动失败的通知需要在AutoScaling组里配置，因为EC2压根没起来，在EC2中创建的状态检查警报并不会响应AutoScaling实例扩展失败

<DOP> ALB和AutoScaling的可用区是分开设置的，ALB决定流量能流到哪个区，AutoScaling决定能在哪个区启动机器，二者需要匹配才能正确工作

<DOP> AutoScaling启动机器后，如果机器没有通过（ALB或EC2的）健康检测会被立即终止，为了防止立即终止，可以设置为StandBy状态用来调试

<DOP> AutoScaling的生命周期钩子可以触发EventBridge，从而调用Lambda函数进行一些额外操作

<DOP> AutoScaling可以在EC2实例启动/删除的成功/失败的时候直接向SNS发通知（而不需要再绕EventBridge，但不是不可以）

<DOP> 通过使用Auto Scaling生命周期钩子，可以在实例部署完成之前修改健康检查的路径，避免在实际部署完成之前被标记为健康状态，从而确保实例只在完全部署完成后才被认为是健康的

<DOP> 可以用AutoScaling的生命周期钩子，在EC2关闭之前（可选：调用lambda函数借助SSM的send_command获取日志）将EC2里的日志推送到S3等

<DOP> AutoScaling组打给EC2的标签不会传播到EBS，需要修改AutoScaling组的启动模板让EBS包含标签

<DOP> 暖池是一些预先启动好的EC2，可以在扩展时移入扩展组，缩容时移出，可以预先装好软件并让它们进入休眠状态将内存里的东西写入硬盘获取最快的启动性能，还可以和生命周期钩子一起做更多初始化

<DOP> 在以下场景中，使用单一ALB后多个ASG：1. 同一应用多版本部署. 2. 多租户系统. 3. 开发、测试、生产等多环境系统. 4. 多AZ间灾备. 5. 业务模块隔离

<DOP> 不一定需要在 ALB 后面建立新的 ASG，可以通过现有的 ASG 和 ALB 的目标组以及流量分配功能来实现金丝雀部署

Lambda

<SAP> Lambda函数会给每个请求产生一个容器，连接RDS就会新增一个连接，这很容易突破MySQL的连接数上限，解决办法是引进RDS Proxy中间层减少连接数，前提是使用SecretManager管理数据库连接信息

<SAP> 在同一个Region下，所有Lambda函数会共用同一个资源池，当一个Lambda函数的并发量提高时，会影响其他所有函数的性能

<SAP> 在Lambda函数的hanlder外编写DB连接等代码，会将静态资源缓存到/tmp下实现复用，以提升性能

<SAP> 降低Lambda的同时执行数，能够控制请求第三方API时的并发量，避免第三方API出现限流错误

<SAP> 切记一定要看清楚如果有处理时间超过15分钟的不要选Lambda

<SAP> 默认配置在VPC外的Lambda函数无法访问VPC内的资源比如私有RDS，如果将Lambda配置在VPC内，则它会获得一个安全组，通过设定就可以访问私有RDS了，如果它的流量想去公网或DynamoDB等公网服务，则需要通过NAT走到IGW，和EC2行为一样（但即便Lambda部署在公有子网，他也无法访问互联网）

<SAP> Lambda函数通过CLI进行金丝雀部署使用的是update-alias命令和--routing-config选项

<DOP> 当Lambda处理DataStream的流数据时，如果发生了错误，可以讲数据拆分为小批次，从而精确定位发生错误的数据，传给DLQ

<DOP> Lambda函数可以配置预置并发数，来减缓函数容器冷启动的时间，可以将读取数据库初始化这类耗时的任务在预初始化的时候就做好

<SCS> 不要在Lambda上使用访问密钥，这容易泄露，要使用IAM角色获取临时凭证

<SCS> 给lambda函数角色添加Policy时，条件是StringEquals SourceArn，而不是CalledVia PrincipalArn

ECR/ECS/EKS

<DOP> ECR支持跨区域复制镜像，避免构建镜像时间长而RTO过短，这种方法想走私有网络需要给源账户的ECR/S3配置终端节点让目标账户拉取

<DOP> ECR通过生命周期策略自动删除超过一定数量的image版本

<SCS> ECR的token过期时间为12小时

<SCS> ECR不允许使用KMS稍后加密，必须重新创建ECR存储库

<SCS> ECR支持使用开源Clair扫描脆弱性，也支持和Inspector集成扫描

<DOP> ECS日志可以通过Task的awslogs参数传递给CW Logs，CW Logs的日志可以通过Firehose传递给S3

<SCS> 使用ECS Exec功能实现对Fargate容器的内存转储（比如使用gcore或gdb）,比CW Logs成本低且不需要修改代码

<SAP> 在EKS上，可以使用Topology Spread Constraints将Pod分散到多AZ实现高可用

Elastic Beanstalk

<SAP> 在使用EB蓝绿部署的时候，可以通过环境URL的swap迅速切换到新环境的CNAME，如果走R53的话，因为DNS有缓存，可能要等待一段时间才能生效

<DOP> EB只能在操作系统级别提供有限的定义，无法针对特定版本的Tomcat、HAproxy等工具进行细微调试，需要使用CodeDeploy对EC2/ECS等更人工的工具部署

<DOP> 无法在.ebextensions配置文件中覆盖指定为EB CLI参数的值，这是个优先级问题

<DOP> 当部署EB错误时，EB本身可以直接配置发电子邮件

<SCS> EB的服务角色用来定义AWS资源，实例配置文件定义EC2上的角色

📝 数据工具

S3

<SAP> 使用S3对象锁，可以防止同名对象被随意覆盖，或者保证在一定时期内不能被删除

<SAP> S3 Transfer Acceleration是使用CF的边缘Location进行传输加速的，适用于全球客户端传送数据到单一Region的S3存储桶，而不应该选择新增CF Distribution加速

<SAP> 账户A里有一个S3存储桶，如果账户B上传文件到这个存储桶里，则账户A无法访问对象（403），解决办法是账户B上传文件时给文件添加bucket-owner-full-control ACL，然而，更推荐的现代解决方案是在账户A的S3存储桶上启用“存储桶所有者强制执行（Bucket owner enforced）”对象所有权设置，这将自动使所有上传的对象归存储桶所有者所有，并禁用ACLs，从而简化权限管理

<SAP> 记录S3的访问日志使用Server Access Logging，然后通过Athena分析（比如抽取奇怪的IP地址），而不是使用CW Logs，S3的日志不会记录进CW Logs

<SAP> 关于S3 Access point，平常都是用桶名访问S3用桶Policy控制权限的，可以增加一些访问点，让不同VPC（不同地方）来的不同流量走不同的入口，分别控制他们的权限

<SAP> 可以使用S3 RTC来控制跨区域拷贝的成功时效性（如是否在15分钟内成功拷贝了数据），并在未达成SLA时发送通知，这是用来监控S3 Replication的最便捷的途径，但如果RPO过短则需要应用层双写

<SAP> 有些没有分析需求的AWS日志，比如ALB日志，比起放在CW Logs里，放在S3上更加省钱（1/30），但CW Logs已经引入分层定价，需要具体讨论

<SAP> S3可以设定要求对象的请求者支付传输费用，这样一来请求者就必须带上--request-payer标记，承认自己要付费后，才能够执行S3命令

<SAP> IAM Access Analyzer可以用来监控S3存储桶对外公开的事件

<DOP> 跨区域复制是一个异步过程，可能会消耗15分钟到几小时，如果想满足5秒这种级别的RPO，则需要用程序写入两份数据到不同存储桶

<DOP> 可以使用Content-MD5和ETag检查文件上传的完整性

<DOP> 不要使用ACL，不推荐了！

<DOP> S3 Access Points主要分为通用型访问点和S3 Object Lambda访问点，通用型简化对桶的访问管理，Object Lambda则允许通过Lambda处理数据

<ANS> 保证S3里的内容传输加密的方法是在桶策略中禁止未加密流量

<SCS> S3对象锁可以保证文件只读，实现一写多读（WORM），其中治理模式允许root用户改写/删除文件，合规模式不允许

<SCS> 必须在MFA认证后才能执行S3操作的策略是：Deny、BoolIfExists、MultiFactorAuthPresent、false

<SCS> 拒绝S3未加密上传文件的桶策略是：Deny、Bool、SecureTransport、false

<SCS> Glacier Vault Lock在24小时验证窗口期内若未调用 complete-vault-lock，则锁ID过期且策略自动移除，不会永久生效

<SCS> S3 Glacier Vault Lock策略一旦进入“锁定”状态，就不能被删除或修改，其核心目的正是限制删除以实现WORM

<SCS> S3 Glacier Vault Lock锁定策略可以通过abort-vault-lock终止锁定，然后重新initiate-vault-lock

<SCS> 使用SSE-KMS比SSE-S3能更好的防止数据泄露，因为前者比后者额外需要KMS密钥的访问权限来解密数据

<SCS> 为防数据上传至组织外S3桶，SCP应在 Deny 语句中对 s3:PutObject 等操作使用 aws:ResourceOrgID 条件键，确保目标桶的组织ID与本组织一致

<SCS> 能否访问一个S3对象是通过三个上下文进行判定的，假设是一个IAM用户或角色访问S3对象：首先判断用户上下文，即用户角色Policy中有没有对应的权限，然后判断桶上下文（桶所有者编写的桶策略），看桶的所有者是否进行了显示Deny，最后看对象上下文（对象所有者编写的对象ACL），看对象的所有者是否分配了对象所有权，如果访问者不是一个IAM用户或角色，比如public访问，则直接从桶上下文开始判断

<SCS> 在S3桶策略中Deny权限会优先覆盖Allow权限

<SCS> 在S3桶策略的Principal中，只能设置单个用户，不能设置用户组

<SCS> S3桶的配置里可以配置强制所有权，让其他账号传来的对象归属S3桶的账号管理

EBS

<SAP> EBS可以用KMS的CMK加密，加密后数据、EBS与EC2的通信、Snapshot及复原后的EBS都会被加密，默认的CMK「aws/ebs」加密，但是它坑在CMK不跨Region，不如自己的CMK，将未加密的EBS加密需要首先获取snapshot，拷贝一份设置加密有效（和RDS一样），加密后的EBS不能取消加密，只能自己把文件拷出去

<SAP> EBS会在IO很低的时候积累credits，在IO很高的时候消耗credits，当credits消耗殆尽时会以最低的IOPS运行，如果此时需要更稳定的IOPS，则需要提升EBS容量来加快credits的获取，或把EBS改成Provisioned IOPS（io1/io2）来满足密集IO负载

<SAP> 提升硬盘吞吐量到3000IOPS的话直接用EBS gp2/gp3就可以了，不需要使用EFS之类更复杂的工具

<SAP> 将EBS从gp2升级到gp3能节约大概20%的成本

<SAP> EBS下面有个叫Data Lifecycle Manager（DLM）的功能专门负责定期生成EBS镜像，虽然AWS Backup也能干这件事但是前者更加简单，问哪个简单就选前者

<SCS> 为了防止EBS的镜像被攻击者删除，建议将加密密钥复制到另一个AWS账户，并且给另外一个AWS账户赋予KMS密钥权限

EFS

<SAP> 应用程序频繁IO访问海量小文件，原则上用EFS，而不是S3，理由是S3的初衷是将大量文件共享给全球用户的，而不是针对单个应用程序做快速IO存取的

<SAP> NAS上云首选EFS而不是Sotrage Gateway，因为1.后者基于S3，到文件系统需要一层转换，2.后者需要很多额外配置，3.后者性能受限于带宽，4.后者不能自动扩容缩容，5.后者的长期成本高

<SAP> 用户文件存在本地磁盘的项目迁移上云时，使用ALB将流量分摊到不同AZ的两台EC2服务器后，不要使用EBS存储文件，因为这样就不知道文件保存在/要保存到两个EBS的哪一个上了，这时需要使用EFS做存储

<SCS> 定期清理EFS上全部数据最简单的方法是用Lambda挂载EFS+EventBridge

RDS

<SAP> Aurora相比RDS具备更高的性能、自动故障转移和可扩展性，更适合在活动峰值等高负载场景中使用

<SAP> 如果想在多个Region之间设置多主节点让R53根据延迟切换主节点，Aurora并不支持这个特性，而DynamoDB可以

<SAP> Aurora Serverless相比Aurora有自动扩展写入能力的功能，更适合应对不可预测的高并发写入

<SAP> Aurora MySQL可以将查询日志直接发布到CW Logs来查找慢查询

<SAP> Aurora能够自动扩容到64或128TB，无需使用其他方式比如Lambda进行人工扩容

<SAP> Aurora有Data Active Stream功能，可以把所有数据活动流式发给Kinesis Data Stream，再进行下一步分析

<DOP> Aurora的Global数据库进行切换能满足秒级RPO，但是贵，通过Route53跨Region切DNS的方式存在10-20秒的数据复制延迟，和30秒到2分钟到Route53故障感知和切换延迟，所以用这种方案最少要能容忍几分钟的RPO

<SAP> 关于RDS保存时加密 RDS的保存时加密和EBS类似，使用CMK，加密对象为数据、自动备份、读节点、镜像和日志，同样对未加密的RDS加密需要拷贝时加密，并且需要保证读节点的加密设置和主节点一致，跨Region拷贝时还要切换到不同Region的CMK

<SAP> 在RDS Proxy的内部有透明性的连接管理功能，能在failover的时候减缓服务停机时间

<SAP> RDS Replica是可扩展性解决方案，而不是高可用解决方案，而多AZ部署的方式是高可用容灾解决方案

<SAP> 可以通过给IAM Role加policy的方式访问RDS，但是RDS的这种认证方式无法和IdP一起使用

<SAP> RDS无法通过制作Replica的方式进行加密，必须针对镜像加密后重建RDS实例

<DOP> Aurora只能在同一Region实现多主

<DOP> RDS不支持开箱即用的跨Region故障转移，只能在灾备区域设置只读副本

<DOP> 自动快照每天创建一次，不能修改这个频率，希望高频备份需要手动创建快照或使用RDS的自当备份功能

<DOP> Aurora故障切换的方法是，把RDS事件通知发给SNS，调用Lambda函数提升Aurora只读副本，并更新Route53将流量切换到备用区域

<DOP> 非Aurora故障切换的方法是，把RDS事件通知发给SNS，调用Lambda函数将灾备区手动启动的只读副本提升为主节点，并更新Route53将流量切换到备

<SCS> 给现有RDS加密的方式是创建快照，用KMS加密创建新快照，再恢复

<SCS> ParameterStore的SecureString可以用来保存数据库身份认证信息

<SCS> 检测RDS是否被不合规地开启了公开访问最好的方法是Config->EventBridge->SNS

DynamoDB

<SAP> 当DynamoDB因为达到读次数限制出现问题时，最快解决问题的方法是切换成ondemand模式

<SAP> 针对DynamoDB特定属性的访问权限控制，是在IAM Role上设置的

<SAP> DynamoDB的DAX没有Savings Plans

<SAP> DynamoDB支持无限量、无期限、多份保存，对于IoT数据，很适合通过Data Seream -> Lambda -> DynamoDB的途径存储，并且把一部分需要实时查询的内容分流到ELK架构上，毕竟Elasticsearch不是无限量存储的，其本身不太适合在海量数据场景下作为一个Storage来用

<SAP> 存储海量小记录（4K以下）可以直接用DynamoDB，而不要考虑在S3上存csv之类的，DynamoDB方便分析

<SAP> Apache Cassandra时一种KVS型数据库，方便移植到Amazon DynamoDB

<SAP> Amazon DynamoDB Streams 是 Amazon DynamoDB 提供的一项功能，用于捕获表的实时变更并将其以流的形式输出，可以使用 DynamoDB Streams 复制表中的变更，以实现跨区域复制或备份需求

Kinesis

<SAP> 用SQS做数据处理入库，如果无法消化海量的请求，那么加DLQ并不能解决问题，因为这只能延缓问题，SQS一样会挂，另外扩展两个/三个SQS也不能保证不会挂，可以考虑使用Firehose，适当容忍数据延迟

<SAP> 如果想分析最近几秒发送过来的数据，成本最低的方式是直接分析Kinesis Data Stream里的数据，如果想分析得时间再长一点，则用Kinesis Data Firehose按照路径存到S3，相比之下，虽然DynamoDB也可以，但是在导出到S3方面需要借助Lambda函数等其他工具，成本和便利性上都上不划算还会引发更多风险

<SAP> Data Firehose可以将一个账户里的CW Logs流式传输到其他账户，实现日志的集中管理

<SAP> Kinesis Data Streams 具备扩展扇出功能，能让每个消费者获取专有的带宽，突破每个分片共享2MB/s读取带宽的限制，Kinesis Data Streams插入的数据是不可变的，除非过期不会被删除，可以有多个程序作为同一个Shard的消费者，而SQS做不到这点，SQS的消息一旦被读取就会被删除不会被另一个消费者看到

<SAP> Kinesis Data Stream每个分片的写入带宽限制是 1MB/s，读取带宽限制是2MB/s

DMS

<SAP> 如果RPO允许一个小时，那么就用DMS实现Aurora的异地灾备，因为比Global Database便宜

<SAP> 在跨数据库种类进行schema转换用DMS移动数据之前，可以先用SCT生成数据转换报告提前解决问题，再使用DMS移动数据

<SAP> AWS DMS旨在实现数据库迁移的最小化停机时间，通过全量加载和持续数据捕获（CDC）来保持源数据库在迁移过程中持续运行，但在最终切换阶段通常仍需短暂停机，DMS通常是直接将数据从源数据库复制到目标数据库，S3作为中间存储是可选的，并非标准工作流程

<SAP> 对于网络管控严格的离线数据上云，可以考虑用SCT转换数据架构再配合Snowball mobile离线传输数据到VPC，相比之下DMS是一个在线传输工具，做选型的时候可能会卡在网络管控上，比如公司禁止数据中心和VPC互联的情况

<DOP> 在DMS中启用多AZ可提供高可用性，具体来说，即使主复制实例中断，在AWS DMS中启用多可用区选项也会自动故障转移到备用实例，从而提高服务可用性

<SCS> 使用DMS可以将未加密的RDS实例里的内容迁移到加密RDS实例中

其他工具

<SAP> AWS Backup可以结合Organization跨账户管理备份

<SAP> 可以将公司内的数据（比如Redshift）通过Data Exchange导出到S3，让其他公司“订阅”，其他公司可以通过API拉取共享出去的数据

<SAP> DataSync是专门用于数据安全迁移的服务，将DataSync配合PrivateLink（Interface型gateway）使用，可以保证数据不走公网的前提下从一个Region或机房迁移到另一个Region

<SAP> ElastiCache Redis的用法分延迟读取和write through，前者先查缓存，如果没有再查库写缓存，后者直接把所有数据同时写入缓存，相比前者，后者没有第一次查询时慢点问题，能靠牺牲存储空间提供更稳定的性能

<SAP> EMR的TaskNode选择Spot Instance即便挂了，EMR任务也会在其他TaskNode上继续跑，因此不能因为题目说“要求最高的稳定性”就舍弃Spot Instance，毕竟这是一种性价比最高的方式，与之相比，Reserved Instance虽然有最高的稳定性，但是考虑TaskNode数可以根据CW指标进行弹性伸缩，性价比反而低

<SAP> Spark做shuffle的时候确实很吃硬盘IO，虽然说对于GB级的数据有足够大的内存就好了，可对几十上百GB乃至TB级的数据来说更大的瓶颈还是在硬盘IO，所以选型的时候建议优先选择优化了硬盘IO的EC2机种而不是内存优化的机种

<SAP> FSx一旦构建就不能修改DeployType成为多AZ结构，只能做备份，可以用DataSync

<SAP> OpenSearch中的UltraWarm是一种用于存储冷数据的选项，它是一种冷热架构，将热数据存储在EBS节点上，冷数据存储在S3上，来提高查询性能，热数据7天后会被移动到冷数据里

<SAP> 在Redshift上可以启动concurrency scaling自动应对大并发请求

<SAP> Storage Gateway分为Gateway-Storage Volumes和Gateway-Cached Volumes，前者把数据都存在本地，异步备份到S3，能保证本地的最佳性能，后者把数据都保存到S3，把频繁访问的保存到本地，保证本地最小空间使用量

<SAP> 磁带网关（Tape Gateway）存储到S3的数据无法直接读取，需要用Storage Gateway才能读取，所以对需要随时访问文件的系统来说不是迁移的选项

<SAP> Storage Gateway的运维成本被认为是相对高的，本地文件系统上云优先选择FSx等服务