亚马逊AWS官方博客

1. 背景介绍 AWS WAF ，全称是Web Application Firewall ，即Web 应用程序防火墙，可以帮助用户保护Web 应用程序免受常见的Web漏洞攻击。通常这些攻击会损害Web应用的安全性，影响可用性，消耗过多的资源，增加成本，还降低响应速度和用户体验。 WAF可以让用户创建定制规则进行流量筛选，阻隔恶意访问，保障正常请求。比如，可以根据 IP 地址、HTTP 标头、HTTP 正文或 URI 字符串来筛选 Web 请求，这样便能阻止诸如 SQL 注入或跨站点脚本等常见攻击模式。 和其它诸多 AWS 服务一样，WAF 的所有功能也可以通过AWS管理控制台或API进行配置。这便利了用户团队的不同角色，不论是开发人员、DevOps工程师还是安全审查专家都可以方便使用，从开发到部署的全过程系统地管理Web应用的安全。 WAF 和AWS的Web相关服务紧密结合，目前支持CloudFront和Application Load Balancer。AWS WAF 让您能够创建集中化的规则集合，而后部署到多个网站上。用户通常有多个网站和 Web 应用程序，使用WAF可以只定义一组规则并复用于多个应用程序上。WAF也是AWS全托管的服务，用户无需担心其扩展和可用性。只需在正确的资源上启用WAF，无需部署任何额外软件即可完成部署。并且只需要部署一次，即可以全球的边缘节点全部生效。 作为防火墙，WAF当然也少不了监控和报警。WAF 可以让用户设置条件来监视哪些请求。提供准实时地 Web 流量监测报告，并以此信息来创建新的规则或使用 Amazon CloudWatch 的进行报警。 今天，我们以WAF实现防盗图这个常见应用场景，帮助大家快速上手，体验其强大和便捷。 2. 部署与配置WAF 现在主流的Web应用都使用了无cookie域名来加速静态内容，我们这里也进行类似的部署，如网站域名是 example.com，图片服务使用另一个域名 example_img.com。禁止盗图的效果可以从下表来概述。 调用图片的域名 响应效果 *.example.com 200 OK 其它非法域名 403 Forbidden WAF目前支持CloudFront和Application […]

作者：Sadegh Nadimi                翻译：郝森 在过去的几年里，AWS专业服务团队已经指导和帮助企业完成数百个迁移项目。今年，我们建立了一个专门的专家团队，称作专业服务大规模迁移团队，专注于协助客户开始大规模迁移（数百个应用）。 客户经常困惑有哪些最佳实践，使应用快速稳健的迁移到AWS. 虽然每个企业的组织架构和业务目标不同，但是大规模迁移团队已经掌握一些模式和实践，帮助每种类型的企业。以下是一个不完全的清单： 迁移前阶段 1. 为未来IT和业务交集的部分，制定一个清晰的愿景。想象这个愿景将怎样影响组织的战略；更广泛的宣传，使大家明确的知道战略对组织非常重要。 2. 规划并分享一个云治理模型。识别更广泛的团队的角色和职责，满足企业信息安全的最小访问特权和职责分立等原则，保障企业目标的达成将有很长的一段路要走。它同样使增强安全管控纳入到更好的控制。在使内部用户进入使用云服务的洪流之前，需要回答很多问题。我应该有多少AWS帐户？谁可以使用什么？你怎么样授予权限？在云治理来临时，AWS可以告诉你每种方法的最佳实践、优势、限制。 3. 在此过程中，尽早的培训员工。团队掌握AWS的相关知识越多，迁移就越顺畅；内部的云布道师越多，就更容易的消除障碍。在组织做一个决定，即决定在AWS之上的最终IT全景视图，这些工作应该尽早展开。 4. 花时间和精力规划AWS之上的运维管理。研究需要调整的流程，有帮助的云运维工具，以及增强团队力量的各级别运维管理培训。思考那些使你关注更宏观图景的运维管理，确保你的环境与业务战略更好的协同。 5.了解当前拥有的IT资产，以及每批迁移中都包含哪些资产。这使你完全量化和衡量你的成功入云过程。花时间找到正确的资产发现工具，更新你的应用清单。这些使迁移规划较为顺畅，使迁移过程中忽略关联关系的风险最小化。 6. 为迁移之旅选择合适的合作伙伴。应该寻找那些既有技术技能和实施经验，又有灵活方法和项目管理框架的合作伙伴。你可能已经有一个具备云能力的合作伙伴，在选择之前，留出时间对合作伙伴进行审查，要求提供参考案例。思考你计划采用的云运维模型，合作伙伴是否可以帮助协同这个模型（建设持续交付持续集成管道，管理服务）。 迁移阶段 7. 从较小的和简单的开始。换句话说，选择一些速赢的方案。你的员工对使用AWS服务越舒服，那么干系人就会越快看到收益，那么在内部推动上就越容易。你需要做到持续和透明，我们已经看到很多组织通过一系列速赢方案而实现成功。 8. 自动化。云灵活性的实现有赖于自动化。花时间重新审视那些流程，并建立一些新的在迁移过程中有用的流程。如果不是所有的方面都能自动化，仔细决定哪些可以，让团队完成。 9. 把云当作转型。通过调整内部流程，使其拥抱技术变化。运用天然的转型优势，与干系人就新的工作模式达成协同。质疑那些总是说“我们一直这样做”的人。 10. 在可能的情况下，更多的运用全托管服务。比如包括Amazon RDS, AWS Directory Service, 和Amazon DynamoDB。由AWS处理日常的维护活动，使你的团队专注于你的客户事务。 迁移后阶段 11. 全面监控。当你的应用实现健壮的架构，综合监控战略将确保你得到所有的细节。考虑到效率和成本的相互制约，你的环境运行状况如何，数据驱动的洞察力将使你做出更聪明的业务决策。 12. 使用云原生的监控工具。在AWS上，有很多工具都可以提供应用级别的洞察和监控能力。运用最适合业务的工具，从长期看，运维人员将会感谢你，业务负责人也会拥有更清晰的数据为决策提供支持。 13. 采用AWS企业支持服务。AWS技术客户经理和帐单管家，是企业支持服务包的一部分，是非常有价值的资源。他们可以是你虚拟云团队的一部分，提供一个AWS中心接触点，和事件升级路径，同时也是技术信息和指导的宝贵资源。 大规模迁移（一次性迁移数百个应用） 14. 建立一个以迁移活动为中心，由团队、工具和流程组成的健壮的迁移工厂。在第一批迁移工作之前，记录并向组织分享相关细节。采用一个灵活的模式，加速应用迁移到AWS的过程；采用一个合适的保障措施，保障关键迁移里程碑的执行，防范相关风险，例如员工休假，或为特殊负载设计的工具发生故障。 15. 提供领导力以及设定迁移工厂的相关标准。考虑建立项目管理团队，总体管理迁移活动，保障合适的交流和沟通，以及变更过程。建立一个云卓越中心，作为撬动整个迁移工程的支点组织。卓越中心提供技术指导，或者更清晰的规定，它的成员自身也要参加迁移工程。总之，伴随迁移工厂，必须设立项目管理团队和卓越中心，确保迁移项目成功。 16. 在整体项目开始后，制定一个新团队成员加入流程。这其实是另外一种形式的培训。需要建立一个专门团队，评估和批准迁移工厂所用的工具。为了优化迁移结果，考虑任命一个更小的团队，在卓越中心之上，寻找对于自我环境中独特的工作效能和模式。鉴于敏捷批次的范围和节奏的不同，迁移可能是数月，甚至是数年才能完成。应该把迁移工厂看作持续发展和进步的一个有机体。 17. 明智的将有天赋的专家分布于敏捷批次团队。对于AWS服务和数据中心应用，确保有足够宽度上和广度上的能力，处理敏捷批次中遇到的小问题。如果在一个敏捷批次中没有合适的资源，可能导致不统一的决策，进而在后续敏捷迁移批次中产生混乱。 18. 当为一个特殊应用决定迁移策略时，考虑不同的标准。如考虑业务目标、路线图、风险情况、成本等。在高阶层次上，你可以决定保持现状平移应用入云，或者在模式上做一些调整。无论是哪种选择，尽可能采纳弹性和节约成本的最佳实践，并对支撑基础架构进行抽象。有一些共同选择是自动扩展、负载均衡、多可用区场景和准确容量估算的EC2实例。如果有意义，随时让你的团队采用AWS最佳实践，并尽快开始优化。 19. 找到模式并设计蓝图。在团队进行规划活动时，基于选定的战略，迁移模式将是确定的。针对这些模式，设计可重用的蓝图，将加快工作负载迁移的速度。不要忘记与迁移团队分享这些蓝图。这可以帮助进行迁移活动的同事，使他们专注于速度和效率，而不用为决定如何迁移有相似特征的应用而担心。 20. 应用测试。迁移工厂的一个关键活动是整合和验证部署到云端的工作负载。每一个应用组件将通过一系列预定义的和文档记录的测试。如果要求应用负责人在项目的早期就提供测试计划，将会比较顺利的得到业务负责人的签字通过。理想情况下，应该有一个模板，以供所有应用负责人提出特定的测试需求。这将帮助验证活动顺利执行，使业务负责人放心，他们的应用在AWS上运行与在数据中心中运行是类似的，甚至是更好的。 […]

在 re:Invent 大会期间发布的文章 (AWS Greengrass – 无处不在的现实世界计算) 中，我首次介绍了 AWS Greengrass。当时我们推出了 AWS Greengrass 的有限预览版，并邀请您注册。 正如我当时指出的那样，许多 AWS 客户希望在现场收集和处理数据，而现场的网络连接通常很慢，有时还时断时续，并不可靠。利用 Greengrass，他们可以在基于现场的小型简单设备上应用 AWS 编程模型。它建立在 AWS IoT 和 AWS Lambda 的基础上，支持访问 AWS Cloud 中不断增加的各种服务。 利用 Greengrass，您可以访问在现场运行的计算、消息收发、数据缓存和同步服务，这些服务并不依赖与 AWS 区域的稳定高带宽连接。您可以在 Python 2.7 中编写 Lambda 函数，并将其从云部署到 Greengrass 设备，同时使用 Device Shadows 来维护状态。您的设备和外设可以使用本地消息收发互相通信，后者并不通过云进行传递。 现已公开发布 今天我们将在US East (Northern Virginia) 和 US West (Oregon) 区域公开发布 Greengrass。在预览版本中，AWS 客户已成功获得 Greengrass […]

在之前的一篇安全相关的文章《从永恒之蓝开始，安全防范没有结束》中，提到通过AWS Config自动规范AWS服务的安全、合规方面的配置。 为更好遵从各行业的合规要求，构建安全的IT环境，企业的安全团队一般都会在明确安全／管理边界的前提下，选择相关安全框架，用对应的风险评估方法梳理出符合自身业务特点的安全模型。根据安全模型，通常也会用各种文档标准化抽象为各种管理策略，例如可能包含以下常见的内容： 用户权限策略 访问控制策略 服务器安全策略 应用接入策略 网络分区策略 数据传输策略 数据存储策略 备份归档策略 日志记录策略 审计管理策略 ………. 在实际的应用场景中，标准策略可能会因为业务的变化或管理方式的变化动态调整，如何持续评估和审核在AWS云端的资源配置的合规性是否与企业规划一致？如何帮助用户在云端更好的实现变更管理，安全分析甚至自动修正不合规的配置 ？这种场景下，可以考虑用AWS Config 服务来帮忙。 一、AWS config 是什么 AWS Config 是一项托管服务,借助 Config您可以盘点AWS 资源、查看配置更改以及 AWS 资源之间的关系并深入探究详细的资源配置历史记录。使用 Config，还能通过自定义规则来定义所需的资源配置、内部最佳实践和指南，并依据这些规则评估您记录的配置。 AWS Config的主要应用功能： 评估您 AWS 资源配置是否具备所需设置。 获得与您的 AWS 账户关联的受支持资源的当前配置快照。 检索您的账户中的一个或多个资源配置。 检索一个或多个资源的历史配置。 在资源被创建、修改或删除时接收通知。 查看不同资源之间的关系。例如，您可能想要找到使用特定安全组的所有资源 AWS Config工作原理 更多AWS Config的信息可以参考https://aws.amazon.com/cn/config/ 二、 AWS config 配置测试 为了更好了解AWS Config的工作过程，以下 将以AWS安全组的配置监控为例做一个简短测试 。 1. 测试场景： […]

AWS在2016年底的re:Invent大会上发布了基于深度学习的图像分析服务Amazon Rekognition, 可以用以检测对象、场景和面孔，可以搜索和比较面孔，还可以识别图像中的不当内容。Amazon Rekognition 通过一系列简单的 API 来提供强大且准确的图像分析功能，消除了在应用程序中构建图像识别功能的复杂性。您无需具备计算机视觉或深度学习专业能力，即可利用 Rekognition 可靠的图像分析功能。借助 Rekognition API，您可以轻松快速地在任何 Web 应用程序、移动应用程序或互联设备应用程序中构建图像分析功能。 最近，AWS又为Amazon Rekognition增加了新的功能——名人识别。这个功能可以识别在政治、娱乐、体育、媒体、商业等各个领域的名人。名人识别是全球性的功能，而名人的名单也会不断增加。 要使用名人识别的功能，只需调用新增的RecognizeCelebrities API。此API首先检测图像中的人脸，然后返回匹配出的名人信息，和该名人在IMDB上的链接（如果有）。 您现在就可以使用AWS管理控制台，通过简单的上传或者拖拽(不会存储您的图像)，体验名人识别的功能。 那我们再来看看Amazon Rekognition都能够识别哪些名人吧。 Amazon Rekognition已经能够识别出新科法网冠军，年仅20岁的拉脱维亚新星奥斯塔彭科。 Amazon Rekognition还能够识别出“国民老公”王思聪和他的父亲王健林。 利用Amazon Rekogntion，妈妈再也不用担心我分不清楚王珞丹和白百何了。 如此强大的Rekognition API 让您能够轻松地在应用程序中构建强大的视觉搜索和发现功能。Amazon Rekognition 已经与常用的 AWS 服务 (如 Amazon S3 和 AWS Lambda) 无缝集成，同时能够提供一致的响应时间而无需预置额外的容量；而且您只需为您分析的图像和存储的面孔元数据付费。无最低费用，无预先承诺。 Amazon AI一致致力于构建人人都能使用的人工智能环境，使每一位开发人员都能能找到适合的人工智能解决方案，更多信息，请参见: https://aws.amazon.com/cn/amazon-ai/ (注: 文章中的图片均来自互联网)   作者介绍 王宇博 AWS资深产品拓展经理，主要负责AWS大数据、人工智能、高性能计算相关服务和解决方案在中国的业务拓展。 在加入AWS之前，他在IBM担任资深产品经理，主要负责虚拟化、云计算等相关产品线在中国的市场战略推广及业务发展。 他具有近15年的IT行业经验，涉及软件开发、技术咨询、解决方案销售、产品策划与管理等领域。

我本人极为推崇亲身体验。我通常只在自己使用过所提及的服务后才会撰写博客文章，不过偶尔也有例外。如果您碰巧阅读了我爱 Amazon WorkSpace 这篇博客文章，您就会知道 Amazon WorkSpaces 是我最重要的生产力工具之一。我想告诉您的是，您将有机会免费试用 Amazon WorlSpaces。新的 Amazon WorkSpaces 免费套餐可让您启动两个标准服务包工作区，并在 2 个月的时间内，每月使用最多 40 个小时。您可以选择 Windows 7 或 Windows 10 桌面体验，这两种产品都以 Windows Server 为强大后盾。这两个选项都包含 Internet Explorer 11、Mozilla Firefox、7-Zip 和 Amazon Workdocs，还有 50 GB 存储空间。要使用此免费套餐，您必须在 AutoStop 模式下运行工作区 (默认情况下将为您选择此模式)。未使用的小时数将在第一个日历月结束时过期，而此免费套餐优惠将在第二个日历月结束时过期。之后，将按照 Amazon WorkSpaces 定价页面上列出的小时费率向您收费。要开始免费试用，请完成快速设置中的步骤，并选择有资格享受此免费套餐的服务包： 此优惠适用于提供WorkSpaces的所有 AWS 区域。 -Jeff

概述 2017年4月旧金山的AWS全球峰会上，一项名为CodeStar的新服务闪亮登场，他帮助您在AWS上快速开发、构建和部署应用程序。从此，AWS对软件开发生命周期的支持，向开发者那端又迈进了一步。 下图为DevOps相关的AWS服务： AWS CodeStar的主要功能包括： 1. 快速开发：可选多种项目模版和编程语言，快速开发基于Amazon EC2、AWS Lambda 和 AWS Elastic Beanstalk 的Web应用程序、微服务和Alexa技能。 2. CI & CD：与其他AWS DevOps服务或第三方工具集成，您可以在几分钟内建立起持续集成和持续部署工具链，从而以更快的速度发布代码。 3. 团队协作：集中管理项目组成员的权限，这些权限被自动应用到项目中所有使用到的服务，无须额外创建复杂的IAM策略。 4. 项目管理：通过Dashboard可以看到项目的整体状况，最新的项目活动（例如最近一次代码变更、编译和发布的结果），还可以与Atlassian JIRA集成以便跟踪和管理问题。 接下来，我们谈一谈如何快速上手这款好用的服务。 前提条件 使用CodeStar之前，需要做一些准备工作，包括： 1. 用户：创建或使用您已有的一个AWS用户，登录控制台，并确认您拥有该用户的access key和secret key。 2. 权限：如果希望该用户可以创建CodeStar项目，则需要赋予他AWSCodeStarFullAccess权限。如果该用户已经被加入其他CodeStar项目，则他已经被分配了相应的权限。 3. 证书：为了将本地的代码变化递交到CodeStar项目，您需要生成一个HTTPS Git证书，用以连接您在云端的私有Repository。请参阅：http://docs.aws.amazon.com/zh_cn/codestar/latest/userguide/getting-started.html#git-credentials 4. 密钥对：如您希望访问CodeStar项目创建的EC2资源，则需要创建或使用一个已有的密钥对。 5. Git：在本地安装Git工具。请参阅：https://git-scm.com/downloads 好了，准备工作完毕，现在开始创建您的第一个CodeStar项目吧！ 开始使用 目前CodeStar仅在EU (Ireland)、US East (N. Virginia)、US East (Ohio)和US West (Oregon)四个区域可用，选择CodeStar服务后，出现如下画面： 第一次使用时，会提示您创建CodeStar的service role，该服务角色将以您的名义创建、管理所选择的资源，并在仪表板中展示资源的信息。 然后，我们会看到CodeStar提供给您丰富的项目模版。本例选择使用Node.js在EC2上搭建一个Web应用程序。 接下来给项目起个名字（自动生成项目ID)；然后勾选“AWS […]

今天似乎是回顾在过去一年左右的时间里我们添加到 [madison] 的一些功能，以及与您分享一些客户成功案例和代码的大好时机！该服务使您可以轻松地在托管的 EC2 实例群集上运行任意数量的 Docker 容器，并获得完整的控制台、API、CloudFormation、CLI 和 PowerShell 支持。您可以将您的 Linux 和 Windows Docker 镜像存储在 EC2 容器注册表中以方便访问。 发布回顾 我们先来看一些最新的 ECS 功能和一些演示如何使用这些功能的有用的操作方法博客文章： 应用程序负载均衡 – 去年我们添加了对应用程序负载均衡器的支持。这一高性能的负载均衡选项在应用程序级别运行，允许您定义基于内容的路由规则。它支持动态端口，并且可以跨多个服务共享，使您更容易在容器中运行微服务器。要了解更多信息，请阅读有关服务负载均衡的信息。 任务的 IAM 角色 – 您可以通过向 ECS 任务分配 IAM 角色来保护您的基础设施。这允许您基于每个任务精细地授予权限，从而可根据每个任务的需要自定义权限。阅读任务的 IAM 角色，了解更多信息。 服务 Auto Scaling – 您可以定义扩展策略，以根据需求的变化来扩展和缩减您的服务 (任务)。您只需设置所需的最小和最大任务数，并创建一个或多个扩展策略，服务 Auto Scaling 将负责其余的工作。服务 Auto Scaling 的文档可帮助您使用此功能。Blox – 在基于容器的环境中，调度是将任务分配给实例的过程。ECS 为您提供三个选项：自动 (通过内置的服务计划程序)、手动 (通过RunTask 函数) 和自定义 (通过您提供的计划程序)。Blox […]

1.概述 Serverless即无服务器架构正在迅速举起，AWS Lambda 和AWS API Gateway作为Serverless 架构主要的服务，正受到广泛关注，也有越来越多用户使用它们，享受其带来的便利。传统上来说，Lambda 和API Gateway主要用以实现RESTful接口，其响应输出结果是JSON数据，而实际业务场景还有需要输出二进制数据流的情况，比如输出图片内容。本文以触发式图片处理服务为例，深入挖掘Lambda 和 API Gateway的最新功能，让它们支持二进制数据，展示无服务器架构更全面的服务能力。 先看一个经典架构的案例——响应式主动图片处理服务。 Lambda配合 S3 文件上传事件触发在后台进行图片处理，比如生成缩略图，然后再上传到 S3，这是Lambda用于事件触发的一个经典场景。 http://docs.aws.amazon.com/lambda/latest/dg/with-s3-example.html 在实际生产环境中这套架构还有一些局限，比如： 后台运行的图片处理可能无法保证及时完成，用户上传完原图后需要立即查看缩略图时还没有生成。 很多图片都是刚上传后使用频繁，一段时间以后就使用很少了，但是缩略图还不能删，因为也可能有少量使用，比如查看历史订单时。 客户端设备类型繁多，一次性生成所有尺寸的缩略图，会消耗较多Lambda运算时间和 S3存储。 如果增加了新的尺寸类型，旧图片要再生成新的缩略图就比较麻烦了。 我们使用用户触发的架构来实现实时图片处理服务，即当用户请求某个缩略图时实时生成该尺寸的缩略图，然后通过 CloudFront缓存在CDN上。这其实还是事件触发执行Lambda，只是由文件上传的事件主动触发，变成了用户访问的被动触发。但是只有原图存储在S3，任何尺寸的缩图都不生成文件不存储到S3。要实现此架构方案，核心技术点就是让Lambda和API Gateway可以响应输出二进制的图片数据流。 总体架构图如下： 主要技术点： 涉及服务都是AWS完全托管的，自动扩容，无需运维，尤其是 Lambda，按运算时间付费，省去 EC2 部署的繁琐。 原图存在 S3 上，只开放给 Lambda 的读取权限，禁止其它人访问原图，保护原图数据安全。 Lambda 实时生成缩略图，尽管Lambda目前还不支持直接输出二进制数据，我们可以设置让它输出base64编码后的文本，并且不再使用JSON结构。配合API Gateway可以把base64编码后的文本再转换回二进制数据，最终就可以实现输出二进制数据流了。 用 API Gateway 实现 图片访问的URL。我们常见的API Gateway用来做RESTful 的API接口，接口的 URL形式通常是 /resource?parameter=value，其实还可以配置成不用GET参数，而把URL中的路径部分作参数映射成后端的参数。 回源 API Gateway，缓存时间可以用户自定义，建议为24小时。直接支持 HTTPS，支持享用AWS全球边缘节点。 CloudFront […]

背景介绍 相信AWS的用户对AWS CloudFormation都不会陌生。AWS CloudFormation是实现IAC（Infrastructure as Code）自动化运维的一项重要服务，可以帮助用户对 AWS资源进行建模和设置，以便能花较少的时间管理这些资源。CloudFormation中有两个重要选项：Mappings段和Parameters段，可以帮助用户组织模板里的参数和映射，让用户更好地自定义堆栈，以实现模板的重用和复用。比方说可以用Mappings管理对应AWS上不同region的AMI ID，或者管理企业内部的不同部门。 但是当用户所在的组织越来越多地采用IAC自动化时，mappings和parameters的数量也会急剧增长，给CloudFormation模板的编写和维护带来复杂度。 解决方案 本文里我们介绍一种方法：用当前流行的Serverless计算AWS Lambda 和Amazon DynamoDB自动地管理AWS CloudFormation模板中的Parameters和Mappings。 本文中主要用到了以下几种 AWS服务： 1、DynamoDB表：Amazon DynamoDB是一个NoSQL数据库，这里我们采用它保存CloudFormation模板中所有的mappings和parameters。不仅可以实现集中存放，而且可以依赖DynamoDB的接口实现方便快速地增删和查找。比方说在我们的sample code中，整个企业采用这样一张表：partition key包括组名（比如说team1、team2等）和环境（比如说development、test、production等），sort key保存应用的名字。这个表里的数据类似这样： 当我们把这些数据都insert到DynamoDB中后，可以在AWS console里看到表中的内容是这样的： 2、Lambda方法：AWS Lambda又称为Serverless的计算，通过它你可以运行你的code而不需要预配置或者管理任何服务器。这里我们采用Lambda方法实现CloudFormation和DynamoDB之间的关联，它从CloudFormation模板接收primary key和sort key作为输入，查找DynamoDB表，并且返回所有的key-value数据。 3、Custom lookup resource：这是CloudFormation里的一个自定义资源，与一个Lambda方法绑定。CloudFormation除了可以定义已有的AWS资源，还支持几种自定义资源，包括这种以Lambda方法作为后端的自定义资源。当这种自定义资源创建、更新或者删除时，CloudFormation自动地向Lambda API发起请求，引发方法并将请求的数据传给Lambda方法，本例中所请求的数据是primary key，返回的数据是key-value数据。通常在一个组织中只需要建立这一个custom resource，所有的CloudFormation模板都可以复用它。下图是sample code里建立的custom resource： 让我们将这几种服务组合起来，并且定义好它们之间的交互顺序，整个解决方案就是下图展示的这样： 那么整个的交互顺序如下： 1、用户创建DynamoDB表，插入所需的mappings和parameters数据。 2、CloudFormation模板中的custom resource调用Lambda方法，用组名和环境名称（“teamname-environment”）作为partition key，用应用名称（”appname”）作为sort key。 3、Lambda方法用partition key和sort key作为输入查询DynamoDB表。 4、DyanamoDB将结果返回给Lambda方法。 5、Lambda方法将这些key-value数据作为结果返回给模板中的custom resource。 6、custom resource拿到数据后，堆栈里的其他资源可以通过Fn::GetAtt的方式获得这些数据。 结论 通过这种方式，可以将我们创建堆栈所需的固定部分保存在模板中，而将可变部分mappings和parameters保存在方便增删改查的DynamoDB中，用Lambda实现两者之间的关联。对于大型组织来说，这样可以提高运维效率，也是使用CloudFormation的一种最佳实践。 参考 可以在我们的网站上下载到相关的sample […]