CSAA PRACTICE TEST 7

8

1. 使用数据库备份：

Amazon RDS 创建并保存数据库实例的自动备份。Amazon RDS 创建数据库实例的存储卷快照，并备份整个数据库实例而不仅仅是单个数据库。

2. Amazon RDS 在数据库实例的备份时段中创建数据库实例的自动备份。

Amazon RDS 根据您指定的备份保留期保存数据库实例的自动备份。如果需要，您可以将数据库恢复到备份保留期中的任意时间点。

3. 自动备份遵循以下规则：

1. 数据库实例必须处于 ACTIVE 状态才能进行自动备份。当数据库实例处于 ACTIVE 之外的状态 (例如 STORAGE_FULL) 时，不会进行自动备份。
2. 在相同区域中有相同数据库实例的副本正在执行时，不会进行自动备份和自动快照。

4. 备份时段：

1. 自动备份在每天的首选备份时段中进行。如果备份所需的时间超过了分配到备份时段的时间，则备份将在该时段结束后继续，直至完成。备份时段不能与数据库实例的每周维护时段重叠。
2. 在自动备份时段期间，启动备份进程时可能会短时间暂停存储 I/O (通常不到几秒)。在备份多可用区部署时，您可能需要等待几分钟。 对于 MariaDB、MySQL、Oracle 和 PostgreSQL，多可用区部署的备份期间不会暂停主数据库上的 I/O 活动，因为备份获取自备用数据库。对于 SQL Server，多可用区部署的备份期间将短时间暂停 I/O 活动。
3. 如果创建数据库实例时不指定首选备份时段，则 Amazon RDS 会分配默认的 30 分钟备份时段，此时段是随机从每个区域的 8 小时时间段中选择的。下表列出了已分配默认备份时段的各个地区的时间块。

5. 备份保留期：

您可以在创建数据库实例时设置备份保留期。如果您未设置备份保留期，则默认备份保留期为 1 天 (如果使用 Amazon RDS API 或 AWS CLI 创建数据库实例) 或 7 天 (如果使用 AWS 控制台创建数据库实例)。对于 Amazon Aurora 数据库群集，默认备份保留期为 1 天，不管创建数据库群集的方式如何。创建数据库实例后，您可以修改备份保留期。您可以将备份保留期设置为在 1 到 35 天之间。对于非 Aurora 数据库引擎，您也可以将备份保留期设置为 0，这会禁用自动备份。手动快照限制 (每个区域 100 个) 不适用于自动备份。

17

1. Aurora调用Lambda需要的设置

1. 保证Aurora Cluster拥有访问Lambda function的角色；
2. 保证Aurora Cluster允许outbound访问Lambda function；

24

1. DynamoDB是一个NOSQL数据库，是通过hash方式进行数据存储调用的。所以选择一个拥有大量不同值的key可以方便提升读写性能；
2. DynamoDB支持两种partition key

1. Partition key: A simple primary key, composed of one attribute known as the partition key. Attributes in DynamoDB are similar in many ways to fields or columns in other database systems.
2. Partition key and sort key: Referred to as a composite primary key, this type of key is composed of two attributes. The first attribute is the partition key, and the second attribute is the* sort key*. Following is an example.

3. 为什么需要Partition keys

1. DynamoDB stores data as groups of attributes, known as *items. *Items are similar to rows or records in other database systems. DynamoDB stores and retrieves each item based on the primary key value, which must be unique. Items are distributed across 10-GB storage units, called partitions (physical storage internal to DynamoDB). Each table has one or more partitions, as shown in the following illustration. For more information, see Partitions and Data Distribution in the DynamoDB Developer Guide.
2. DynamoDB uses the partition key’s value as an input to an internal hash function. The output from the hash function determines the partition in which the item is stored. Each item’s location is determined by the hash value of its partition key.
3. All items with the same partition key are stored together, and for composite partition keys, are ordered by the sort key value. DynamoDB splits partitions by sort key if the collection size grows bigger than 10 GB.

4. Partition keys and request throttling

1. DynamoDB evenly distributes provisioned throughput—read capacity units (RCUs) and write capacity units (WCUs)—among partitions and automatically supports your access patterns using the throughput you have provisioned. However, if your access pattern exceeds 3000 RCU or 1000 WCU for a single partition key value, your requests might be throttled with a ProvisionedThroughputExceededException error.
2. Reading or writing above the limit can be caused by these issues:

1. Uneven distribution of data due to the wrong choice of partition key
2. Frequent access of the same key in a partition (the most popular item, also known as a hot key)
3. A request rate greater than the provisioned throughput

3. To avoid request throttling, design your DynamoDB table with the right partition key to meet your access requirements and provide even distribution of data.

8. Recommendation for Partition keys

1. use high-cardinality attribute
2. Use composite attribute
3. Cache popular items
4. Add random numbers or digits from a predetermined range for write-heavy use cases

25

1. S3的主要特征

1. 较低的延迟和较高的吞吐量性能
2. 可跨多个可用区实现 99.999999999％ 的对象的持久性
3. 数据在整个可用区遭到破坏时具有弹性
4. 经过设计，可在指定年度内实现 99.99% 的可用性
5. 以 Amazon S3 服务等级协议作为后盾，实现可用性
6. 支持传输中数据 SSL 和静态数据加密
7. 对象自动迁移的生命周期管理

2. S3-IA的主要特征

1. 和 S3 标准相同的较低延迟和较高吞吐量性能
2. 可跨多个可用区实现 99.999999999％ 的对象的持久性
3. 数据在整个可用区遭到破坏时具有弹性
4. 经过设计，可在指定年度内实现 99.9% 的可用性
5. 以 Amazon S3 服务等级协议作为后盾，实现可用性
6. 支持传输中数据 SSL 和静态数据加密
7. 对象自动迁移的生命周期管理

3. S3-IA one zone 主要特征

1. 和 S3 标准及 S3 标准 – IA 相同的较低延迟和较高吞吐量性能
2. 可在单个可用区中实现 99.999999999% 的对象的持久性，但是数据将在可用区销毁时丢失
3. 可在指定年度内实现 99.5% 的可用性
4. 以 Amazon S3 服务等级协议作为后盾，实现可用性
5. 支持传输中数据 SSL 和静态数据加密
6. 对象自动迁移的生命周期管理
7. 由于 S3 单区 – IA 将数据存储在单个 AWS 可用区中，存储在这个存储类中的数据将在可用区销毁时丢失。

4. Glacier的主要特征

1.  可跨多个可用区实现 99.999999999％  的对象的持久性
2.  数据在整个可用区遭到破坏时具有弹性
3.  支持传输中数据 SSL 和静态数据加密
4.  成本极低，非常适合长期存档
5.  对象自动迁移的生命周期管理

5. Glacier的的检索特性：

Amazon Glacier 为适应您的使用案例，提供了三种检索选项。加速检索（小于250M的文件）通常可在 1 至 5 分钟内返回数据，非常适用于 Active Archive 使用案例。标准检索完成工作通常需要 3 至 5 小时，非常适用于时效性较低的需求，如备份数据、媒体编辑或长期分析。批量检索是成本最低的检索选项，可在 5 至 12 小时内返回大量数据。

29

1. 将Kinesis Data Stream 与接口VPC终端节点一起使用：您可以使用接口 VPC 终端节点，以防止 Amazon VPC 和 Kinesis Data Streams 之间的流量离开 Amazon 网络。接口 VPC 终端节点不需要 Internet 网关、NAT 设备、VPN 连接或 AWS Direct Connect 连接。接口 VPC 终端节点由 AWS PrivateLink 提供支持，后者是一种 AWS 技术，可将弹性网络接口与您 Amazon VPC 中的私有 IP 结合使用来支持 AWS 服务之间的私有通信。有关更多信息，请参阅 Amazon Virtual Private Cloud。
2. 对Kinesis Data Stream使用接口VPC端点：要开始使用，您不需要更改流、创建者或用户的设置。只需创建一个 VPC 终端节点以使您的 Kinesis Data Streams 流量进出 Amazon VPC 资源，从而开始流过接口 VPC 终端节点。

1. Kinesis Producer Library (KPL) 和 Kinesis Consumer Library (KCL) 使用共有终端节点或私有接口 VPC 终端节点 (二者中在使用中的那个) 调用 AWS 服务 (例如 Amazon CloudWatch and Amazon DynamoDB)。例如，如果您的 KPL 应用程序在启用 DynamoDB 接口 VPC 终端节点的情况下在 VPC 中运行，则 DynamoDB 和您的 KCL 应用程序流之间的调用会流过接口 VPC 终端节点。

3. VPC 终端节点当前在以下区域受支持：暂时是15个region，如美国俄勒冈、亚太孟买、新加坡等

35

1. CloudTrail可以创建两种类型的跟踪

1.  应用于所有区域的跟踪
2.  应用于一个区域的跟踪
3.  注意：这两种类型的跟踪的存储可以设置到任何一个**S3**的桶中;

37

1. AUTO SCALING:Amazon EC2 Auto Scaling 帮助您确保您具有适量的 Amazon EC2 实例可用于处理您的应用程序负载。您可创建 EC2 实例的集合，称为Auto Scaling 组。您可以指定每个 Auto Scaling 组中最少的实例数量，Amazon EC2 Auto Scaling 会确保您的组中的实例永远不会低于这个数量。您可以指定各个 Auto Scaling 组中的最大实例数量，Amazon EC2 Auto Scaling 会确保您的组中的实例永远不会超过这个数量。如果您在创建组的时候或在创建组之后的任何时候指定了所需容量，Amazon EC2 Auto Scaling 会确保您的组一直具有此数量的实例。如果您指定了扩展策略，则 Amazon EC2 Auto Scaling 可以在您的应用程序的需求增加或降低时启动或终止实例。
2. AutoScaling的关键组件

1. 组：您的 EC2 实例整理到组 中，从而将其作为一个逻辑单位进行扩展和管理。当您创建一个组时，您可以指定其中 EC2 实例的最小数量、最大数量以及所需数量。有关更多信息，请参阅 Auto Scaling 组。
2. 启动配置：组使用启动配置 作为其 EC2 实例的模板。创建启动配置时，您可以为实例指定诸如 AMI ID、实例类型、密钥对、安全组和块储存设备映射等信息。关于更多信息，请参阅 启动配置
3. 扩展选项：Amazon EC2 Auto Scaling 提供了多种方法来扩展您的 Auto Scaling 组。例如，您可以将组配置为在发生指定条件时（动态扩展）或根据时间表进行扩展。有关更多信息，请参阅扩展选项。

39

1. ACL：网络访问控制列表(ACL) 是 VPC 的一个可选安全层，可用作防火墙来控制进出一个或多个子网的流量。您可以设置网络 ACL，使其规则与您的安全组相似，
2. 网络ACL规则：

1. 规则编号。规则评估从编号最低的规则起开始进行。只要有一条规则与流量匹配，即应用该规则，并忽略与之冲突的任意更高编号的规则。
2. 协议。您可以指定任何有标准协议编号的协议。 有关更多信息，请参见Protocol Numbers。如果您指定 ICMP 作为协议，您可以指定任意或全部 ICMP 类型和代码。
3. [仅限入站规则]数据流源 (CIDR 范围) 和目标端口 (监听) 或端口范围。
4. [仅限出站规则]数据流目标 (CIDR 范围) 以及目标端口或端口范围。
5. 针对特定流量选择 ALLOW 或 DENY。

3. 默认网络ACL：默认网络 ACL 配置为让所有流量流进和流出与其关联的子网。每个网络 ACL 还包含一个规则编号是星号的规则。此规则确保在数据包不匹配任何其他编号规则时拒绝该数据包。您可以修改或删除此规则。

43

1. 两层网络的部署架构web layer and db layer，需要保证web层的SG设置正确的规则可以访问数据库；

58

1. Kinesis Data Firehose：Amazon Kinesis Data Firehose 是一个完全托管的服务，用于将实时流数据传输到目标，例如，Amazon Simple Storage Service (Amazon S3)、Amazon Redshift、Amazon Elasticsearch Service (Amazon ES) 和 Splunk。Kinesis Data Firehose 与 Kinesis Data Streams、Kinesis Video Streams 和 Amazon Kinesis Data Analytics 都是 Kinesis 流式处理数据平台的一部分。在使用 Kinesis Data Firehose 时，您无需编写应用程序或管理资源。您可以配置数据创建器以将数据发送到 Kinesis Data Firehose，后者自动将数据传输到您指定的目标。您还可以配置 Kinesis Data Firehose 以在传输之前转换数据。

61

1. AWS DATA PIPELINE:

AWS Data Pipeline 是一项 Web 服务，您可用于自动处理数据的移动和转换。使用 AWS Data Pipeline，您可以定义数据驱动的工作流，这样任务就可以依赖于前面任务的成功执行。您可以定义数据转换的参数，AWS Data Pipeline 将实施您设置的逻辑。

2. AWS Data Pipeline可以与以下组件协同服务：

1. 管道定义 指定数据管理的业务逻辑。有关更多信息，请参阅管道定义文件语法。
2. 管道通过创建 Amazon EC2 实例以执行定义的工作活动，来计划和运行任务。您将管道定义上传到管道，然后激活管道。您可以编辑正在运行的管道的管道定义，并重新激活管道以使其生效。您可以停用管道，修改数据源，然后重新激活管道。完成使用管道后可以将其删除。
3. Task Runner 将轮询任务，然后执行这些任务。例如，Task Runner 可以将日志文件复制到 Amazon S3，然后启动 Amazon EMR 集群。Task Runner 已安装，并将在管道定义所创建的资源上自动运行。您可以编写自定义任务运行程序应用程序，也可以使用 AWS Data Pipeline 提供的 Task Runner 应用程序。有关更多信息，请参阅任务运行程序。

3. DynamoDB中处理时间序列数据的最佳实践

1. 考虑您想跟踪大量活动的典型时间序列场景。您的写入访问模式即要记录的所有事件都具有今日日期。您的读取访问模式读取今日事件的频率最高，读取昨日事件的频率小很多，而读取更早事件的频率是最低的。
2. 读取访问模式通过将当前日期和时间构建为主键得到了最佳处理。但这肯定会创建一个或多个热分区。最新分区始终是正在写入到的唯一 分区。所有其他分区 (包括之前日期的所有分区) 都会将配置的写入容量从最需要它的位置转移。
3. 以下设计模式通常会高效地处理此类场景：

1. 为每个时间段创建一个表，每个分区键值配置少于 1000 个写入容量单位 (WCU) 的写入容量以及最少必要读取容量
2. 在每个时间段结束之前，为下一个时间段预构建表。在当前时间段结束时，事件流量将定向至新表。可以为这些表分配名称以指定表已记录的时间段。
3. 只要表不再被写入，就将其配置的写入容量降至 1 WCU 并配置适当的读取容量。当之前的表变旧时减少其配置的读取容量，存档或删除很少需要或根本不需要其内容的表。
4. 这旨在确保配置的写入容量得到充分使用而不是由未写入内容的分区稀释。使用其值 (如时间值) 单调地更改的分区键，这意味着尝试阻止拆分任何物理分区。这是因为，在拆分后，所有后续写入操作将仅对拆分所生成的两个分区之一执行。

62

1. ELB：Elastic Load Balancing 支持以下类型的负载均衡器：

应用程序负载均衡器、网络负载均衡器 和 传统负载均衡器，而且 Amazon ECS 服务可以使用任一类型的负载均衡器。应用程序负载均衡器 用于路由 HTTP/HTTPS (或第 7 层) 流量。网络负载均衡器 和 传统负载均衡器 用于路由 TCP (或第 4 层) 流量。

2. 应用负载均衡非常适合于ECS搭档：

应用程序负载均衡器 提供了一些新功能，这使其非常适合用于 Amazon ECS 服务：

1. 应用程序负载均衡器 允许容器使用动态主机端口映射（以便每个容器实例允许来自同一服务的多个任务）。
2. 应用程序负载均衡器 支持基于路径的路由和优先级规则（以便多个服务可使用一个 应用程序负载均衡器 上的相同侦听器端口）。

64

1. ELB定义：

Elastic Load Balancing 跨多个可用区中的多个目标 (如 Amazon EC2 实例、容器和 IP 地址) 分布传入的应用程序或网络流量。Elastic Load Balancing 会在应用程序的传入流量随时间的推移发生更改时扩展负载均衡器，并可自动扩展来处理大部分工作负载。

2. 从传统负载均衡迁移到ALB的好处

使用应用程序负载均衡器而不是传统负载均衡器具有以下优势：

1. 支持基于路径的路由。对于根据请求中的 URL 转发请求的侦听器，您可以为它配置规则。这让您可以将应用程序构造为较小的服务，并根据 URL 内容将请求路由到正确的服务。
2. 支持基于主机的路由。对于基于 HTTP 标头中主机字段转发请求的侦听器，您可以为它配置规则。这使您能够使用单个负载均衡器将请求路由到多个域。
3. 支持将请求路由到单个 EC2 实例上的多个应用程序。可以使用多个端口向同一个目标组注册每个实例或 IP 地址。
4. 支持通过 IP 地址注册目标，包括位于负载均衡器的 VPC 之外的目标。
5. 支持容器化的应用程序。计划任务时，Amazon Elastic Container Service (Amazon ECS) 可以选择一个未使用的端口，并可以使用此端口向目标组注册该任务。这样可以高效地使用您的群集。
6. 支持单独监控每个服务的运行状况，因为运行状况检查是在目标组级别定义的，并且许多 CloudWatch 指标是在目标组级别报告的。将目标组挂载到 Auto Scaling 组的功能使您能够根据需求动态扩展每个服务。
7. 访问日志包含附加信息，并以压缩格式存储。
8. 已改进负载均衡器性能。

3. Network Load Balancer:

Network Load Balancer在开放系统互连 (OSI) 模型的第四层运行。它每秒可以处理数百万个请求。在负载均衡器收到连接请求后，它会从默认规则的目标组中选择一个目标。它尝试在侦听器配置中指定的端口上打开一个到该选定目标的 TCP 连接。

4. Classic Load Balancer：

负载均衡器在多个可用区中的多个 EC2 实例间分配应用程序的传入流量。这可以提高应用程序的容错能力。Elastic Load Balancing 会检测运行状况不佳的实例，并且仅将流量路由到运行状况良好的实例。

1. 您的负载均衡器将作为客户端的单一接触点。这将提高应用程序的可用性。可以根据需求变化在负载均衡器中添加和删除实例，而不会中断应用程序的整体请求流。Elastic Load Balancing 根据传输到应用程序的流量随时间的变化对负载均衡器进行扩展。Elastic Load Balancing 能够自动扩展来处理绝大部分工作负载。
2. 优势：支持 EC2-Classic、支持 TCP 和 SSL 侦听器、支持使用应用程序生成的 cookie 的粘性会话；

4. 当设计高可用架构的时候

首先是跨AZ，划分多个子网，当发现web层不需要被外部访问的时候，可以也放到private subnet子网里边；不一定只有db instance放到private subnet；