使用 Python 书写 AWS Lambda 的一个好处就是能够在控制台中直接编辑源代码，非常方便进行快速验证测试 AWS 环境相关的。这只限于使用 AWS 为 Python Lambda 运行时提供的默认组件(比如 boto3)，尚若需要在自己的 Python Lambda 中使用其他的组件(如 redis), 就不得不把自己的代码及依赖打成一个 zip 包再部署，这时候就无法在控制台直接编辑代码了，也只能坠入本地修改代码，重新打包上传测试的循环当中。
欲了解 Python Lambda 中除了 boto3 外还能直接使用别的什么组件，可点击此链接 https://gist.github.com/gene1wood/4a052f39490fae00e0c3 查看当前。该 gist 也还提供了代码 code to run in Lambda 来获得所有依赖。试了下在 Python Lambda 中，用通常的help('modules') # 或
竟然连大名鼎鼎的 boto3 都无法列出来。
help('modules package')
回到正题来，如果既想用第三方的依赖，又想要在控制台中直接编辑代码进行测试，是否有他法呢？有，那就是 AWS 在 2018 年 11 月推出的 Lambda 层。见 AWS Lambda Now Supports Custom Runtimes and Enables Sharing Common Code Between Functions, 这里的层除了能用来提供 Python 依赖，还许自定义运行时，如 C++ 或 Rust 等写 Lambda 都不是梦。
AWS 的服务就像个大口袋，何时偷偷的加添了什么服务，或出了什么新的我，不时关注它的 What's New with AWS 必是个好习惯。 Read More在用 Python 编写 AWS 服务时，要用到 Boto 3 组件，而像 boto3.client('s3') 获得的对象只能被 IDE 识别为一个 BaseClient, 具体包含什么操作方法是在运行时由参数
s3指示的基于 JSON 文件所描述的。因此 IDE 对s3 = boto3.client('s3')的s3对象无法提供有效的智能提示，每次用 Boto 3 时不得不打开 Boto 3 的在线 API 文档来对照。长此以往，总觉麻烦且效率低下，有种一直摸着石头过河的感觉。那么，是否有办法让 IDE 智能提示出各种 boto3.client('<service>') 的实际操作呢？网上找了找，确实有这个需求，解决办法有- botostubs: 与 boto3 API 保持更新(每三天)，并支持众多 IDE, 试过在 IntelliJ IDEA 和 Visual Studio Code 中可用
- pyboto3: 上次更新在两年前, https://github.com/wavycloud/pyboto3, 只在 Python 2.7 下测试过
- autoboto: 需有智能提示，但改变了应用 Boto 3 组件的方式，不建议使用
本文重点推荐 botostubs, 下面会叙说具体理由，在进入正是之前，不妨来回顾一下直接使用 Boto 3 时没有好的智能提示的问题 Read More
目前我们在 AWS 上把密钥，API Key 等信息是存储在 AWS Systems Manager 的 Parameter Store 中，它只提供了用 KMS Key 加密存储字符串的功能，最大字符串大小是 4096 个字符，它是免费的。
最近发现 AWS 上有一个新的服务 AWS Secrets Manager(2018 年 4 月发布的)，听起来用它来存储密钥信息更高大上些。它同样提供了用 KMS Key 加密存储字符串的功能，字符串最大也是 4096 个字符。从 AWS Web 控制台上看可配置用 Key/Value 的形式，其实本质也是存储为一个 JSON 字符串。
Secrets Manager 与 Parameter Store 更多的功能是能与 RDS 集成 -- 选择数据库收集数据库的配置信息(主机名，端口，实例等), 还有就是可配置定期更新密钥，这对一个安全的系统定期改密码很重要。对于定期更新密钥的未作深入研究，AWS Secrets Manager 本身知道如何轮换 RDS 数据库的密钥，其他的需要一个 Lambda 来支持。 Read More
Amazon 在 2018 年 6 月份宣布可以设置用 SQS 来触发 Lambda，SQS 不再是单纯用于 ECS 服务中，或用于伸缩控制的。这儿就来亲自尝试一下用 SQS 驱动的 Lambda，以及要注意的要素。
首先使用 Java 编写 Lambda 的话，AWS 在 com.amazonaws:aws-lambda-java-events:2.20 版本开始加入了 com.amazonaws.services.lambda.runtime.events.SQSEvent 类，可是这个版本的 aws-lambda-java-events 是有所限的，因为
SQSEvent.SQSMessage类是私有的，这就造成不能获取到 SQSEvent 中的记录数据。//下面的操作代码无法编译，因为 SQSEvent.SQSMessage 是私有的，不可访问
SQSEvent.SQSMessage sqs = sqsEvent.getRecords().get(0);
sqsEvent.getRecords().get(0).getBody();Java 使用 SQS 来驱动 Lambda 的话，至少需要 com.amazonaws:aws-lambda-java-events:2.2.1 版本，从此 SQSEvent.SQSMessage 变成 public 了。该版本是于 2018 年 6 月传到 Maven 官方中央仓库的，这就是那时才能真正用来写 Java 的 SQS 触发的 Lambda.
同时此篇也是作为上文 AWS Lambda 重试与死信队列(DLQ) 的一个很重要的补充。在此也会验证 SQS 触发的 Lambda 的重试机制以及 DLQ 相关的内容。 Read More
AWS Lambda 允许设置
Debugging and error handling, 在 Lambda 出现异常，达到最大的重试次数后，把以下信息放到选择的 SNS 或 SQS 主题作为死信队列(DLQ - Dead Letter Queue)，包括- 原始 Lambda 接收到的消息(基于 SNS 和 SQS 消息的总大小，可能会被截取，本人猜测，尤其是 Kinesis 的消息会比较大)
- 原始 Lambda 的 RequestId
- ErrorCode（三位数字的 HTTP 错误码）
- ErrorMessage, 即原 Lambda 抛出 Exception 的 getMessage() 信息，截取 1 KB 字符串
并且 Lambda 要使用 DLQ 的话还必须设置当前 Lambda 的 IAM role 有对于 SNS/SQS 主题相应的
sns:Publish和sqs:SendMessage权限。AWS Lambda 基本重试规则：对于 Kinesis 消息会无限重试直至消息过期，对于 SNS 或 SQS 的消息出现异常后会再重试两次。参考：AWS Lambda Retry Behavior。
而在重试次数用完后仍然失败，并且设置了 DLQ 的话就会发送消息到 DLQ 中去。 Read More
- 当我们把数据搬上云端，为了保护敏感数据一定要对数据存储进行加密。而对于 S3 上的数据加密最简单莫过于启用服务端数据加密，可以是 AES-256 或 AWS-KMS。进行了服务端加密码的文件有什么不同呢？首先从 AWS S3 文件列表视图中看到的文件大小与原始文件大小是一样的，其实数据在 AWS 机房是加密存储了的，比如说直接在 AWS 服务器上拷出那些 S3 文件是不能理解的。
本文涉及的内容包括：- 服务器端加密后的 S3 文件有何不同
- 不启用 Bucket 的默认加密如何进行服务端数据加密(含 AWS CLI 和 Java 代码操作)
- 启用及应用 Bucket 的默认加密
- 上传与下载文件的 IAM role 需要的权限
服务器端加密后的 S3 文件有何不同
首先看现象，后面才能确认我们的操作是否对数据真的进行了服务端加密。查看使用 AWS-KMS key 加密后的 S3 文件的Overview, 看到下面两个属性Server-side encryption
没加密的话, Server-side encryption 是 None, 并且没有 KMS key ID 属性。 Read More
AWS-KMS KMS key ID
arn:aws:kms:us-east-1:123456789012:key/e4ce859b-786b-4b8e-8b73-4968adb6e4ed - AWS Batch 提供了简单有效的方式来运行 Docker 镜像，在单纯执行一个计算任务时比 ECS 使用起来要方便许多。AWS Batch 在提交任务时可以执行
command,environment和parameters, 那么它将如何传递那些参数给 Docker 容器呢？
首先看一下提交任务的脚本1aws batch submit-job \ 2 --job-name test-job \ 3 --job-queue test-job-queue \ 4 --job-definition test-job-definition \ 5 --container-overrides='command=echo,hello,environment=[{name=JAVA_OPTS,value=-Xmx4G}]'
注：aws cli 命令参数中有-时需要用 --parameters='--name=Spring' 等号的格式
我们将用上面的脚本提交一个任务，然后用docker inspect <container-id>观察 Docker 容器收到了什么参数
也没什么意外的，inspect 容器后我们看到 Read More - 和 Lambda 类似，AWS 的 SQS 队列也提供了 DLQ(Dead Letter Queue) 来支持重试功能，可以设定某一个消息在接收多次重新变得可见后进入到另一个 SQS 队列中。比如说队列 user-id-queue，设定了它的 Redrive Policy 为三次接收后转入到另一个 SQS 队列 user-id-dlq, 就会显示为
Maximum Receives 3
Dead Letter Queue arn:aws:sqs:us-east-1:<account_id>:user-id-dlq在运用 SQS 的 DLQ 之前首先要理解 SQS 中消息的几个概念- Message Available: SQS 客户端可以获取到的消息, 即 Visible Messages
- Messages in Flight: 消息被 SQS 收取了之后，由 Available 转为 In Flight, 该状态的消息不能被客户端接收到
- Visibility Timeout: 消息停留在 In Flight 状态的时间, 如果在 Timeout 之前未删除这个消息，该消息重新变为 Available 状态
我们可以设置 SQS 队列的默认 Visibility Timeout 大小，也可以在代码中收取消息时指定这个值。
所以我们能够在集群环境中应用 SQS 的这个特性让多个节点同时监听单个 SQS 队列，基本上保证每个节点处理各自不同的消息。有一种例外就是：假设我们设置了 Visibility Timeout 是 30 秒，客户端 1 获取到消息后，消息变为 In Flight 状态，但 30 秒后仍然在处理过程中，此时消息回到Available 状态，客户端 2 也能获取到该消息，这也会造成单条消息的重复处理。解决的办法之一是适当延长 Visibility Timeout 的时间，给予第一个客户端更充分的处理时间。 Read More - Docker 镜像在未指定仓库时默认是从 Docker Hub 拉取的。如果需向 Docker Hub 推送镜像的话还可用
docker login在交互中完成登陆 Docker Hub 的操作。docker login的命令格式是docker login [OPTIONS] [SERVER]
所以我们可以连接到任何的 Docker 镜像仓库，也可以是本机，但我们这里所要介绍的是如何推送镜像到 AWS 给我们提供的 Docker 镜像仓库(Amazon ECR - Amazon Elastic Container Registry)。每个帐号下都有自己独立的仓库，镜像推送到了 Amazon ECR 后我们能够很方便的在 ECS, Batch 服务中使用它，也可以从 ECR 拉取镜像到本地来。
首先我们来做一个运行 Spring Boot Web 的简单的 Docker 镜像，假定已用mvc pacakge生成了一个可独立运行的 jar 包java-webapp-0.0.1-SNAPSHOT.jar。该应用开启一个 Web 服务，访问 http://localhost:8080 显示一行字符串Hello World!
创建一个目录 aws-docker, 并把java-webapp-0.0.1-SNAPSHOT.jar移入该目录，在其下创建Dockerfile文件，文件目录结构如下：aws-docker
Read More
├── Dockerfile
└── java-webapp-0.0.1-SNAPSHOT.jar 探索是否能以流式写数据到 S3
通常，在我们项目中用 Java 代码上传数据到 S3 是下面那样的操作
AmazonS3 s3Client = AmazonS3ClientBuilder.defaultClient();
s3Client.putObject("bucket_name", "s3key.txt", new ByteArrayInputStream("hello".getBytes()), new ObjectMetadata()); //ObjectMetadata 没什么特别的话可以为 null虽然 putObject() 的第三个参数是一个流，但它是输入流, 并非输出流啊。也就是说在执行该方法时必须把所有待上传的上据全部准备在这个输入流中，所以这里就直接用一个 ByteArrayInputStream 来包裹需上入到 S3 的数据内容。
当然 putObject() 也就无法像 FileObjectOutputStream 那样流式写入内容到文件中，因为 putObject() 前后都没有与 bucket 上那个文件上有联系。即使是用 PipedInputStream/PipedOutputStream 也不行, 比如说下面的代码 Read More