亚马逊AWS官方博客

Tag: 管理工具

使用 CloudWatch Logs,Kinesis Firehose,Athena 和 Quicksight 实时分析 Amazon Aurora 数据库审计日志

关系数据库管理系统支撑着最重要的联机交易类应用,存放着最重要的数据资产,所以在用户IT系统里占据着非常核心的位置。现实情况往往是审计功能虽然使用并不复杂的统的商业数据库管理系统,但是鲜见有用户打开审计功能。Amazon Aurora MySQL全新发布,高级审计功能强劲在哪,本期大咖专栏带你一探究竟。

Read More

使用“运行命令”管理一组实例

Emily Freebairn,亚马逊AWS软件开发工程师 翻译 Ye Zhou | 原文链接 通常,工程师希望在一组实例中执行操作任务。 但是,这些任务中的许多任务需要以受控的速度进行,并在出现问题时获得反馈。 此外,管理员还通常希望确保工程师只能执行指定的操作。 “运行命令”是Amazon EC2系统管理器(SSM)的一部分,旨在让您远程和安全地管理实例。 “运行命令”提供了一种简单的方法来自动执行常见的管理任务,如运行shell脚本、安装软件或修补程序等等。 “运行命令”允许您在多个实例上执行命令,并提供对结果的可见性。通过与AWS身份和访问管理(IAM)的集成,您可以精确控制用户可以在实例上执行的操作权限。 “运行命令”执行的所有操作均由AWS CloudTrail记录,允许您审核对系统的更改。 在本文中,演示了如何执行命令来收集实例的诊断信息。 由于系统容量是按需添加,系统的容量会随时变化。为了减少实例出现意外的可能性,命令可以以受控的速度运行。 如果出现失败,您将收到通知以进行事后分析。 要确保您不会意外运行其他命令,请使用具有锁定权限的自定义操作来执行指定任务。 演练 在本节中,我将向您展示如何使用Auto Scaling设置实例,创建自定义SSM文档,然后在Auto Scaling组中的所有实例上运行命令。 同时展示了如何设置Amazon CloudWatch事件,以便在遇到问题时收到通知。 步骤1:使用Auto Scaling组启动实例 要使用“运行命令”,实例需要以下内容: 安装并运行Amazon SSM代理 出站互联网连接 附加适当的IAM角色 SSM代理与“运行命令”服务通信以接收命令并发送输出,并使用IAM角色授予调用服务的权限。 对于这篇文章,使用Auto Scaling组来创建一组正确配置的实例。 有关分步说明,请参阅Auto Scaling入门。 这里是一个使用了五个实例的Auto Scaling组的示例。 步骤2:创建自定义文档 “运行命令”使用文档来指定要在实例上执行的操作。文档是由JSON定义的AWS资源,它们包括您指定的步骤和参数。 AWS提供了一组执行常见任务的文档,例如运行shell脚本,配置CloudWatch,安装应用程序等。 此外,您可以为自己的文档编写特定任务。 因为IAM策略允许您控制用户被授权使用哪些文档,因此可以通过将一个指定用户限制到某个文档子集来锁定该用户可以执行的操作。 这里是一个文档的例子,它找出最消耗内存的进程。 { “schemaVersion”: “2.0”, “description”: “Instance Diagnostics”, “parameters”: { }, […]

Read More

使用 AWS CloudFormation StackSets 跨多个 AWS 账户和区域配置资源

AWS CloudFormation 可帮助 AWS 客户实施基础设施即代码模型。客户现在无需手动设置自己的环境和应用程序,他们可以生成一个模板,然后使用它来创建所有必需的资源 (统称为 CloudFormation 堆栈)。此模型彻底消除了人工错误的可能,提高了效率,能够确保始终一致的配置。 今天,我准备为大家介绍一个让 CloudFormation 变得更加有用的新功能。此功能可帮助您应对在包含多个 AWS 账户和/或 AWS 区域的情况下使用基础架构即代码时的挑战。快速回顾: 账户 – 正如前面提到的那样,很多组织使用大量的 AWS 账户,通常用 AWS Organizations 将这些账户组织为分层结构,分组为不同的组织部门 (OU) (阅读 AWS Organizations – 基于策略的多 AWS 账户管理了解更多信息)。我们的客户使用多个账户满足业务部门、应用程序和开发人员所需。他们通常为每一个应用程序的开发、测试、生产前调试及生产阶段创建不同的账户。 区域 – 客户也可以充分利用数量众多 (一直在增长) 的 AWS 区域。他们构建跨越两个或更多区域的全球应用程序,实施精巧的多区域灾难恢复模型,实时复制 S3、Aurora、PostgreSQL 和 MySQL 数据,为依据国家和地区法规存储和处理敏感数据选择位置。 多账户和多区域的扩展对管理和一致性带来了新的挑战。客户告诉我们,他们希望确保每一个新账户都按照其内部标准进行设置。首先他们需要一致、可靠地设置 IAM 用户和角色、VPC 和 VPC 子网、安全组、配置规则、日志记录和 AWS Lambda 函数。 介绍 StackSet 为了满足这些重要的客户需求,我们今天推出 CloudFormation […]

Read More

全新 – Amazon CloudWatch 高精度自定义指标和警报

Amazon CloudWatch 自 2009 年年初以来一直是 AWS 的重要组成部分。CloudWatch 与 Auto Scaling 和 Elastic Load Balancing 三个产品包组合在一起发布,它已发展成为功能极强、面向 AWS 云中运行的 AWS 资源和应用程序的监控服务。CloudWatch 自定义指标 (早在 2011 年发布) 可用在 CloudWatch 中存储业务和应用程序指标、以图形方式查看这些指标,并基于 CloudWatch 警报启动操作。不用说,这些年来,我们的 CloudWatch 增强了很多的功能!最近的一些增强功能包括延长指标保留期 (以及一项用户界面更新)、控制面板、控制面板 API/CloudFormation 支持以及控制面板上的警报。 一开始,指标是按照五分钟的时间间隔存储的;后来,在 2010 年,应客户请求缩短到一分钟 (也称为详细监控)。这是一个广受欢迎的改变,但现在我们可以做得更好。我们的客户在流式传输视频、开展限时抢购、每天上百次部署代码,并随着情况的变化非常快速地扩展和缩减应用程序。对于所有这些情况,一分钟为时间间隔还是太长了。这样有可能错过重要的瞬间高峰;分散 (然而事实上相关) 的事件难以跨越时间进行关联,并且在发生故障时的 MTTR (平均修复时间) 过高。 全新的高精度指标 今天,我们将增加对高精度自定义指标的支持,我们还计划以后逐渐增加对 AWS 服务的支持。现在您的应用程序可以以 1 秒的精度将指标发布到 CloudWatch。在发布指标数秒后您就可以在屏幕上滚动查看这些指标,您还可以设置高精度 CloudWatch 警报,可以精细到每 10 秒评估一次。 想象一下可用内存较少时发出警报。这通常是一种瞬时的情况,如果取样不够频繁,将很难捕获到。使用高精度指标,您可以在数秒内查看、检测 (通过警报) […]

Read More

新功能- Collectd的Amazon CloudWatch插件

原文:https://aws.amazon.com/blogs/aws/new-cloudwatch-plugin-for-collectd/ 作者:Jeff Barr 我在2011年已介绍过Cloud Watch的特性,“您可以在Cloud Watch中查看图表、设置告警、并根据这些指标启动自动化操作,所使用的这些AWS资源指标会被存储于Cloud Watch中 。”您目前已有能力在Amazon Cloud Watch中存储一段时间范围内的业务、应用及系统的指标数据(参阅“Amazon Cloud Watch定制新指标”了解更多信息)。 今天我们将简化系统统计信息的采集过程,使用一个新的 CloudWatch plug for colletd将采集数据发送至CloudWatch中 。并通过collectd 多种类型信息的统计采集能力与cloudwatch存储、展示、警报和告警的功能的整合,您可以更好地获取EC2实例、本地硬件以及运行于其上应用程序的运行状态及其性能信息。该插件已经作为一个开源项目发布,我们期待您的反馈。 Collectd守护进程采用C语言编写,具有高性能和可移植性。它支持上百个插件 ,允许您收集有关Apache、Nginx Web服务器性能统计数据、memory usage 、 uptime等信息。 安装与配置 为了演示这些功能,我在EC2实例上安装并配置了Collectd服务及新Cloudwatch插件。 首先我创建了一条IAM策略,它具备将指标数据写入CloudWatch的权限: 然后我创建了一个IAM角色,允许EC2(运行collectd程序的实例)使用上述所建的策略: 如果我计划使用Collectd 插件从本地服务器或运行中的EC2实例收集统计信息,那请跳过这些步骤,采用创建一个具有适当权限的IAM用户作为替代方法。在我完成上述工作后,会将该用户的证书放在本地服务器或EC2实例中。 在策略和角色配置完毕后,选择该角色来启动一个EC2实例 登录并安装Collectd : $ sudo yum -y install collectd 然后获取插件和安装脚本,设置脚本为可执行,并运行该脚本: $ chmod a+x setup.py $ sudo ./setup.py 回答一些交互问题确认安装过程无误,在完成配置之后就可启动Collectd : Installing dependencies … OK Installing […]

Read More

使用 Amazon EC2 Run Command 在不使用 SSH 访问的情况下大规模地管理实例

以下博文的投稿者为 Ananth Vaidyanathan (EC2 Systems Manager 高级产品经理) 和 Rich Urmston (Pegasystems 公司云架构高级总监),介绍了如何使用 EC2 Run Command 在不使用 SSH 的情况下管理大量 EC2 实例。 -Jeff 企业通常具有若干托管环境和成千上万的 Amazon EC2 实例。安全地管理系统非常重要,同时也要避免棘手的安全外壳 (SSH)。Run Command 是 Amazon EC2 Systems Manager 的一部分,可以让您以可控制和可审查的方式对实例 (或使用标签的实例组) 运行远程命令。这有效地提升了每天都要依赖 Run Command 服务的 Pega 云操作的效率。 您可以通过标准 IAM 角色和策略控制 Run Command 访问,定义文档以获取输入参数,控制用于返回命令输出的 S3 存储桶。您还可以与其他 AWS 账户共享文档或将文档公开。总而言之,Run Command 提供了一组很有用的远程管理功能。 优于 SSH Run […]

Read More

使用Amazon EC2 Systems Manager取代堡垒机

通常情况下,堡垒机(也称为“跳转机”)是在系统中访问私有主机的一个最佳实践。例如,您的系统可能包含一个不希望被公开访问的应用服务器,当需要在这台服务器上进行产品的更新或系统补丁程序的管理时,您通常会登录到堡垒机,然后从那里访问(即“跳转到”)应用服务器。 本文将向您介绍使用Amazon EC2 Systems Manager替换您的堡垒机,实现在服务器上运行命令的同时缩小系统攻击平面并获取更好的可见性。 堡垒机方案 堡垒机最好仅向特定的IP地址范围开放,这个地址范围通常可设定为您单位的企业网络。使用堡垒机的好处是,任何对内部服务器的访问都被限定到一种方式:通过单个或一组堡垒机。为了获取进一步的隔离,堡垒机通常被安放在单独的VPC中。 这种设计方案如下图所示: 应用服务器运行在与管理VPC对等相连的一个VPC的私有子网中。 应用服务器设定了一个安全组规则,其仅允许来自管理VPC中堡垒机所在安全组的22端口访问(本文的示例仅针对端口22和SSH访问。Windows用户可将其相应的替换为端口3389和RDP访问)。同样,堡垒机也设定了一个安全组规则,其仅允许来自公司网络IP地址空间的22端口访问。 由于应用服务器运行在私有子网中,所以它只能通过VPC公共子网中的NAT网关来建立出站公网连接。 假设您希望查看应用程序服务器的网络接口,您需要执行以下步骤: 将应用服务器的私钥安装在堡垒机上。 从可信网络(如公司网络)发起,在堡垒机上建立SSH会话。 从堡垒机发起,建立SSH会话到应用服务器。 运行“ifconfig”命令。 如需保存命令的结果,您可以复制和粘贴命令的输出,或者将输出重定向到文件。 这个方案中的安全措施限制了对应用服务器和堡垒机的访问,但堡垒机模式存在一些缺点: 像任何基础设施服务器一样,堡垒机必须进行管理和维护。 运行时会产生成本。 允许堡垒机访问的每个安全组都需要设置一个安全组入口规则,即SSH(用于Linux)的22端口或RDP的3389端口(用于Windows服务器)。 堡垒机和应用服务器的RSA密钥需要进行管理、保护和轮换。 SSH操作无缺省日志记录。 替代方案 Systems Manager允许您在被管理的服务器上远程执行命令,而不使用堡垒机(此功能称为EC2 Run Command)。安装于服务器上的代理程序会自动轮询Systems Manager以确定是否有命令在等待执行。 此方案具备以下优点: 使用AWS托管服务,这意味着Systems Manager组件具备高可用性。 Systems Manager通过IAM策略设定是否允许用户或角色远程执行命令。 Systems Manager代理程序需要IAM角色和策略才能允许它们调用Systems Manager服务。 Systems Manager不可更改的记录每个执行的命令,从而提供了可审计的命令历史,包括:  o   执行命令的内容  o   执行命令的主体  o   执行命令的时间  o   命令的输出摘要 当AWS CloudTrail在当前区域中启用时,CloudTrail会记录每个事件,并写入Amazon CloudWatch Logs。 使用CloudTrail和CloudWatch规则,您可以将Systems Manager事件用作自动响应的触发器,例如Amazon SNS通知或AWS Lambda函数调用。 […]

Read More

新增 – 面向 Amazon CloudWatch 控制面板的 API 和 CloudFormation 支持

我们在几年前发布了 CloudWatch 控制面板。在专为这次发布撰写的文章中,我介绍了如何以交互方式创建控制面板,以便以图形形式显示所选的 CloudWatch 指标。发布之后,我们增加了其他功能,包括全屏模式、深色主题、控制 Y 轴的范围、简化的重命名、持久性存储和新的可视化选项。 新 API 和 CLI 虽然控制台支持非常有利于交互式使用,但许多客户要求我们提供对控制面板及其中小部件的编程式创建和操作的支持。这些客户想要动态构建和维护控制面板,从而在创建和销毁相应的 AWS 资源时添加和删除小部件。其他客户则希望在两个或多个 AWS 账户中设置和维护一组一致的控制面板。 我非常高兴地宣布,面向 CloudWatch 控制面板的 API、CLI 和 AWS CloudFormation 支持现已推出,您可以立即开始使用! 我们新增了四个 API 函数 (和等效的 CLI 命令): ListDashboards / aws cloudwatch list-dashboards – 用于提取账户内所有控制面板的列表,或共享通用前缀的子集。 GetDashboard / aws cloudwatch get-dashboard – 用于提取单个控制面板的详细信息。 PutDashboard / aws cloudwatch put-dashboard – 用于创建新控制面板或更新现有控制面板。 DeleteDashboards / aws cloudwatch […]

Read More

通过AWS Config 管理AWS服务配置

在之前的一篇安全相关的文章《从永恒之蓝开始,安全防范没有结束》中,提到通过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. 测试场景: […]

Read More

使用AWS Lambda和Amazon DynamoDB自动管理AWS CloudFormation模板中的Parameters和Mappings

背景介绍 相信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 […]

Read More