在今天的文章中，我整理出了大量当初以前错过、而至今仍将我追悔莫及的Amazon Web Services（简称AWS）使用心得。

在几年来的实践其中，我通过在AWS之上新手构建及部署各类应用程序而积累到了这些经验。尽管内容有些杂乱，但相信仍然能给各位带来一点启发。

从物理server向“云环境”转移的过程不仅仅是一项技术任务，同一时候也意味着我们的思维方式须要作出针对性的转变。整体而言，在物理环境下我们须要关注的仅仅是每一台独立主机; 它们各自拥有自己的静态IP，我们可以对其分别加以监控。而一旦当中一台发生问题，我们必须尽最大可能让其高速恢复运转。大家可以以为仅仅要将基础设施转移到AWS环境之下，就能直接享受到“云”技术带来的种种收益了。遗憾的是。事情可没那么简单（相信我，我亲身尝试过了）。在AWS环境之下。我们必须转变思维，并且这方面的任务往往不像技术难题那么easy被察觉。因此，受到了SehropeSarkuni近期一篇帖子的启示，我将自己几年来积累得出的AWS使用心得汇总于此，并且说实话、我真希望自己当初刚刚接触AWS时能有人告诉我这些宝贵经验。这些心得总结自我在AWS之上部署个人及工作应用程序时的亲身感受，当中一部分属于须要高度关注的“疑难杂症”（我自己就是直接受害者），而还有一部分则是我听其它朋友说起过、并随后亲自确认有效的解决方式。只是整体而言，为了积累这些经验。我确实付出了相当慘痛的代价：）

应用程序开发

千万不要把应用程序状态保存在自己的server上。

之所以这么说，是由于一旦我们的server发生问题，那么应用程序状态非常可能也随之彻底消失。

有鉴于此。会话应当被存储在一套数据库（或者其他某些集中式存储体系、memcached或者redis其中）而非本地文件系统内。

日志信息应当通过系统日志（或者其他类似方案）进行处理，并被发送至远程位置加以保存。上传内容应当直接指向S3（举例来说，不要将其存储在本地文件系统内。并通过其他流程随后迁移到S3）。再有，不论什么已经处理过或者须要长期执行的任务都应该通过异步队列（SQS非常适合处理此类任务）来实现。

编辑点评:对于S3上传内容而言，HN用户Krallin指出，我们能够彻底避免其与自有server的接触，并利用预签名URL保证用户的上传数据被直接发送至S3其中。

将额外信息保存在日志其中。

日志记录通常包括有时间戳以及pid等信息。

大家也可能希望将实例id、服务区域、可用区以及环境（比如分步环境或者生产环境等）加入进来。而这些都能在日后的调试工作中作为參考。大家可以从instance metadata service其中获取到这些信息。

我所採用的方法是将这些信息作为引导脚本的组成部分，并将其以文件形式存储在文件系统其中（比如/env/az或者/env/region等）。

这样一来，我就用不着持续查询元数据服务来获取这些信息了。

大家应当确保这些信息可以在实例又一次启动时得到正确更新，毕竟我们都不希望在保存AMI时发现其中的数据还跟上次全然一样，这肯定属于非正常状况。

假设我们须要与AWS进行交互。请在当前语言中使用相应SDK。

千万不要试图自己动手。我当初就犯过这个错误。由于我觉得自己仅仅是单纯须要向S3上传内容，但随着兴许服务的持续添加、我发现自己的决定简直愚蠢至极。AWS SDK的编写质量非常高，可以自己主动处理验证、处理重试逻辑。并且由Amazon官方负责维护与迭代。此外，假设大家使用EC2 IAM角色（大家绝相应该这么做，这一点我们后面会进一步提到）。那么该SDK将帮助我们自己主动获取到正确的证书。

利用工具查看应用程序日志。

大家应当採用管理员工具、系统日志查看器或者其他方案。从而帮助自己在无需在执行中实例内使用SSH的方式查看当前实时日志信息。假设大家拥有集中式日志记录系统（我强烈建议大家使用此类系统），那么当然希望能在不使用SSH的情况下完毕日志内容查看任务。非常明显，将SSH引入正处于执行状态的应用程序实例会引发诸多弊端。

运营心得

假设将SSH引入自己的server。那么自己主动化机制恐怕将无法生效。

在所有server上禁用SSH訪问。

这听起来确实有点疯狂，我知道，但在大家的安全组其中、请务必确保port22不向不论什么人开放。假设各位想从今天的文章中获得什么启发，那请千万牢记下面一点：假设将SSH引入自己的server，那么自己主动化机制恐怕将无法生效。

从防火墙级别（而非server本身）禁用SSH有助于整套框架实现思维转变。由于这样一来我们就能了解到哪些区域须要进行自己主动化改造，同一时候大家也能更轻松地恢复訪问来解决当前面临的问题。

在意识到再也不必将SSH引入实例之后。大家肯定会像我一样感到浑身轻松。

没错，这是我在实践中了解到的最惊世骇俗、但也却具有用性的心得。

编辑点评:非常多人对这项心得表现出了高度关注（HackerNews站点上还出现了不少值得一读的评论意见）。因此我们要在这里多说几句。

我个人也会通过禁用入站SSH来蒙骗自己主动化机制（哦，我仅仅是SSH一下来修复某个问题，立即就撤）。

当然，假设我须要在某个实例中进行主动调试，那么我仍然能够在安全组中将其又一次启用，由于有时候我们确实没有其他办法来调试特定问题。

另外，详细情况还取决于我们实际使用的应用程序类型：假设大家应用程序的正常执行要求各位能力通过SSH将信息传递至server。那么将其禁用肯定不是什么好主意。

这样的阻断进站SSH的办法确实适合我，也迫使我对自己的自己主动化机制加以精心打理，只是必须承认、这样的方式并不适合每一位用户。

server不过临时性手段。不是必需太过关注。

我们要关注的不过服务本身。

假设某台server出现了故障，大家全然不是必需对其太过关注。这是我在利用AWS来替代物理server之后，亲身获得的最直接的便利成效。一般来讲，假设一台物理server无法正常工作，技术人员总会临时陷入恐慌。但在AWS其中，大家就全然不必操心了，由于自己主动伸缩机制会非常快帮我们建立起新的实例。Netflix公司在此基础之上还跨出了更具前瞻意义的步伐。他们组建了Simian Army团队。并尝试Chaos Monkey等极为激进的測试项目——它会随机关闭生产环境下的某些实例（他们还利用Chaos Gorilla项目随机关闭可用区。我甚至得到消息，说是Chaos Kong项目会直接关闭基础设施大区……）。总而言之，我想表达的意思是：server总会发生问题。但这不该影响到我们的应用程序。

不要为server提供静态/弹性IP。

对于一款典型的Web应用程序。大家应当将一切部署在负载均衡机制之下，并在不同可用区之间对资源使用情况加以平衡。尽管我也遇到过一些须要使用弹性IP机制的情况，但为了尽可能提高自己主动伸缩效果，大家还是应该利用负载均衡机制代替在每一个实例中使用独有IP的作法。

将自己主动化普及到各个角落。

不仅仅是AWS。自己主动化机制应该作为总体运营工作中的通用性指导方针，当中包含恢复、部署以及故障转移等等。软件包与操作系统更新都应该由自己主动化方案所管理。详细可表现为bash脚本或者Chef/Puppet等。我们不该把主要精力放在这些琐碎的杂事上。正如前文中所提到。大家还须要确保禁用SSH訪问，从而高速了解到自己的运行流程中还有哪些方面没有实现自己主动化改造。请记住前面提到的重要原则：假设将SSH引入自己的server。那么自己主动化机制恐怕将无法生效。

每位员工都要拥有一个IAM账户。

永远不要登录主账户。

通常情况下，我们会为服务设置一个“运营账户”，而整个运营团队都将共享登录password。

但在AWS其中，大家当然不希望遵循相同的处理方式。每位员工都要拥有一个IAM账户，其中提供与其需求相符的操作权限（也就是最低权限）。

IAM用户已经能够控制基础设施中的一切。截至本文撰写时，IAM用户惟一无法訪问的就是计费页面中的部分内容。

假设大家希望进一步保护自己的账户，请确保为每位员工启用多因素验证机制（大家能够使用谷歌Authenticator）。我听说有些用户会将MFA令牌交付给两名员工，并将password内容交付给另外两名员工。这样主账户在运行随意操作时、都至少须要两名员工的允许。对我来说这样的作法有点小题大做。但或许您所在的企业确实须要如此高强度的控制机制。

我最后一次从CloudWatch收到操作警告大约是在一年之前……

将警告信息转化为通知内容。

假设大家已经将一切步骤正确部署到位。那么执行状态检查机制应该会自己主动清除故障实例并生成新的实例。

在收到CloudWatch警告信息时。我们一般不须要採取不论什么行动，由于全部应对措施都能以自己主动化方式实现。

假设大家得到警告称相关问题须要手动干预，那么请做好事后检查、看看能不能找到一种可以在未来通过自己主动化方式将其解决的途径。

我最后一次从CloudWatch收到操作警告大约是在一年之前，并且对于不论什么一位运营人员来说、可以不再被警告消息打搅了清梦都应该算是天大的好消息。

计费机制

建立起细化计费警告机制。

大家应当始终设定至少一套计费警告机制，但其内容却能够很easy——比如仅仅在我们超出了当月资源用量限额时发出提醒。假设大家希望早点掌握计费指数的动向，则须要一套更为完备的细化方案。我解决问题的办法是以星期为单位设定预期使用量。如此一来。假如第一周的警告额度为1000美元。那么第二周应该为2000美元。第三周为3000美元，依此类推。

假设第二周的警告在当月的14号或者15号之前就被触发。那么我就能推定肯定发生了什么异常状况。假设想更进一步地实现细化控制，大家能够为每项服务设置独立的警告方案，这样就能高速了解究竟是哪项服务把我们的资源预算早早耗尽了。假设大家每一个月都在固定使用某几项服务，并且当中一些很稳定、还有一些则起伏较大，那么这样的方法能够收到良好的成效。在此类情况下，我们最好还是为稳定服务设置每周独立警告，同一时候为起伏较大的服务设置周期更长的总体警告。

当然。假设各项服务的资源使用量都很稳定，那么上述方法就有点过分慎重了，毕竟仅仅要看一眼CloudWatch、大家就能立即了解究竟是哪项服务出了问题。

安全性保障

使用EC2角色。不要为不论什么应用程序提供IAM账户。

假设大家在应用程序其中内置有AWS证书，那么肯定属于“处理失当”的状况了。前面之所以强调在开发语言中使用AWS SDK，最重要的理由之中的一个就是我们可以轻松借此使用EC2 IAM角色。角色的设计思路在于。同意大家为特定角色指定其所必需的恰当权限。而后将该角色分配至相应EC2实例其中。而不管我们何时将AWS SDK应用至实例其中，都不必再指定不论什么验证凭证。相反，该SDK将回收我们在设置其中为该角色指定权限所使用的不论什么暂时性证书。

整个流程都会以透明化方式处理，很安全并且极具有用性。

将权限分配至组，而非用户。

管理用户往往是件令人头痛的事情。特别是在使用Active Directory或者其他一些已经与IAM相整合的外部验证机制时，并且这类作法的实际效果也不够理想（当然也有效果不错的情况）。

只是我发现更轻松的办法，即仅仅将权限分配至组而非个别用户，这将大大减少权限的管理难度。非常明显，相较于面向每位独立用户来查看为其分配的权限，以组为单位进行权限交付可以帮助我们更好地把握系统总体概况。

设置自己主动化安全审计机制。

在日常工作中，非常重要的一点是追踪基础设施内安全设置的各项变更。实现这一目标的办法之中的一个在于首先建立起一套安全审计角色（即JSON模板）。这一角色会对账户之内与安全相关的各类设置进行仅仅读訪问。

在此之后，大家就行利用这一类似于Python脚本的方案达到目标了，它将可以对账户中的全部条目进行审查并生成一整套与配置相关的规范比对结果。我们可以设置一个cronjob来执行该脚本，并将输出结果与上一次的结果相比較。

其中的差异之处就代表着我们安全配置方案其中所出现的变化。这样的方式非常有用，并且可以通过电子邮件将变更信息通知给大家。

使用CloudTrail来记录审计日志。

CloudTrail通过通过API或者S3存储桶内的Web控制台记录所有运行过的操作活动。

利用版本号控制机制设置存储桶能够确保不论什么人都无法改动这些日志内容。而我们自己则能够随后对账户内的所有变更进行彻底审计。我们当然不希望遇到须要审计日志内容的状况，但正所谓有备无患，准备好这么一套方案还是非常有必要的。

S3

在存储桶内的SSL名称中使用“-”而非“.”。

假设大家希望在SSL之上使用自己的存储桶。那么使用“.”作为名称的组成部分将导致证书不匹配错误。一旦存储桶创建完毕。我们将无法再对其名称进行更改。所以大家仅仅能将一切拷贝到新的存储桶其中。

我发现文件系统就像大型政府部门一样“可靠”。

避免加载文件系统（比如FUSE）。

我发如今被用于关键性应用程序时。这些文件系统就像大型政府部门那样“可靠”。总之。使用SDK作为替代方案更加明智。

我们用不着在S3之前使用CloudFront（但这样确实可以起到助益）。

编辑评论:依据Hacker News站点用户的最佳反馈内容。我们对这条心得作出了部分改动。

假设大家对于可扩展能力比較看重，那么最好是将用户直接引导至S3 URL而非使用CloudFront。S3可以实现随意水平的容量扩展（尽管一部分用户报告称其无法实现实时规模扩展），因此这也是充分发挥这一优势的最佳思路。除此之外。更新内容在S3中的起效速度也够快，尽管我们仍然须要在使用CDN查看变更时等等TTL的响应（只是我相信大家如今已经可以在CloudFront中获得0延迟TTL，所以这一点或许存在争议）。

假设大家须要良好的速度表现，或者须要处理对传输带宽要求极高的数据（比如超过10TB），那么大家可能更希望使用像CloudFront这种CDN方案与S3相配合。

CloudFront能够极大提升全球各地用户的訪问速度，由于它会将相关内容拷贝到各边缘位置。依据实际用例的不同。大家能够通过较低数量的请求实现高传输带宽（10TB以上），并借此减少使用成本——这是由于相较于S3传输带宽。当传输总量高于10TB时CloudFront的传输成本每GB比其低0.010美元。只是CloudFront的单次请求成本较直接訪问S3中的文件却要略高一点。依据详细使用模式，传输带宽的成本节约额度或许会超过单一请求所带来的额外成本。由于在直接訪问S3存储内容时，我们仅仅需以较低频度从S3获取数据（远较正常使用情况更低），所以成本也就更加低廉。AWS官方提供的CloudFront说明文档解释了怎样将其与S3配合使用，感兴趣的朋友能够点击此处查看细节信息。

在密钥开头使用随机字符串。

这初看起来似乎有点难以理解，只是S3所採取的一大实现细节在于。Amazon会利用对象密钥来检測某个文件究竟保存在S3中的哪个物理位置。因此假设多个文件使用相同的前缀，那么它们终于非常可能会被保存在同一块磁盘其中。通过设置随机性密钥前缀。我们可以更好地确保自己的对象文件被分散在各个位置。从而进一步提升安全性。

EC2/VPC

别忘了使用标签！

差点儿每项服务都提供标签功能，别忘了善加利用！

它们很适用于进行内容归类。从而大大简化兴许出现的搜索与分组工作。大家也能够利用这些标签在自己的实例中触发特定行为，比如env-debug标签能够确保应用程序在部署之后进入调试模式。

我遇到过这类问题，感觉非常不好。大家千万不要重蹈覆辙！

在非自己主动伸缩实例中使用中止保护。以后你会感激我的建议的，绝对。

假设大家拥有某些不具备自己主动伸缩机制的一次性实例，则应当尽可能同一时候使用中止保护，从而避免某些人无意中将这些实例给删除掉。

我就遇到过这类问题，感觉非常不好，大家千万不要重蹈覆辙！

使用VPC。

当初我刚刚開始接触AWS时。VPC要么还不存在、要么就是被我给忽视了。尽管刚開始上手感觉非常糟糕，但一旦熟悉了它的特性并可以顺畅使用，它绝对能带来令人喜出望外的便捷效果。

它可以在EC2之上提供各类附加功能，事实证明设置VPC花掉的时间全然物有所值——甚至物超所值。首先。大家可以利用ACL从网络层面上控制流量，此外我们还可以改动实例大小及安全组等等。同一时候无需中止当前实例。

大家可以指定出口防火墙规则（在正常情况下。我们无法控制来自EC2的离站流量）。只是最大的助益在于，它能为我们的实例提供独立的私有子网，这就彻底将其它人排除在外，从而构成了额外的保护层。不要像我当初那样傻等着了，立马使用VPC并让一切变得更加轻松。

假设大家对于VPC抱有兴趣，我强烈建议各位观看《百万数据包的一日之期》这段资料。

利用保留实例功能来节约大量成本。

保留实例的本质就是将一部分资金节约下来，从而使其保持较低的资源耗费速率。事实证明，保留实例相较于按需实例可以帮助我们省下大量经费。

因此。假设大家意识到仅仅须要继续保持某个实例执行一到三年，那么保留实例功能将是各位的最佳选择。保留实例属于AWS其中的一类纯逻辑概念。大家用不着将某个实例指定为需保留对象。我们要做的就是设定好保留实例的类型与大小。接下来不论什么符合这一标准的实例都将处于低速运转加低成本支出的执行模式之下。

锁定安全组。

假设有可能，千万不要使用0.0.0.0/0。确保使用特定规则来限制用户对实例的訪问。举例来说。假设大家的实例处于ELB之后。各位应该将安全组设定为仅仅同意接受来自ELB的流量。而非来自0.0.0.0/0的流量。

大家能够通过将“amazon-elb/amazon-elb-sg”写入CIDR的方式实现这一目标（它会自己主动帮大家完毕其余的工作）。

假设大家须要为一部分来自其他实例的訪问请求向特定port放行。也不要使用它们的相应IP。而最好利用其安全组标识符来替代（仅仅须要输入‘sg-’，其他的部分将自己主动完毕）。

不要保留无关的弹性IP。

我们所创建的随意弹性IP都会成为计费项目，不管其与实例是否相关。因此请确保在使用过后将其及时清理掉。

ELB

在负载均衡器上中止SSL。

大家须要将自己的SSL证书信息加入到ELB其中，但在server上中止SSL可以消除由此带来的常规资源消耗，从而提高执行速度。除此之外，假设大家须要上传自己的SSL证书，则可以经由HTTPS流量实现、而负载均衡器会为我们的请求加入额外的标头（比如x-forwarded-for等），这有助于我们了解终于用户到底是何许人也。相比之下，假设我们经由TCP流量实现，那么这些标头将不会被加入进来、相关信息自然也就无从获取。

假设打算运行高强度流量。请对ELB进行预热。

对于ELB来说。容量扩展是须要一段时间周期才干完毕的。假设大家意识到自己将会迎来流量峰值（比如销售门票或者召开大型活动等），则须要提前对ELB进行预热。我们能够主动添加流量规模。这样ELB就会提前进行容量加入，从而避免实际流量来暂时发生卡顿。

只是AWS建议大家最好是与服务人员取得联系，而非自行对负载均衡器进行预热。或者。大家也能够在EC2实例其中安装自己熟悉的负载均衡软件并加以使用（比如HAProxy等）。

ElastiCache

使用配置端点而非独立节点端点。

通常情况下，大家须要让应用程序识别出各可用Memcached节点的存在。但假设大家希望以动态方式实现容量扩展，那么这样的作法可能会带来新的问题。由于我们将须要採取多种方式才干保证应用程序识别到容量的变化。

比較简便的解决方式在于使用配置端点，这意味着使用Memcached库的AWS版本号来对新节点自己主动发现机制加以抽象并剥离。AWS使用指南中提供了很多其它与缓存节点自己主动发现议题相关的解答。感兴趣的朋友能够点击此处查看细节信息。

RDS

为故障转移设置事件订阅机制。

假设大家正在使用多可用区方案，那么这可能是一种被各位所忽略、但在相关需求出现时却又悔之晚矣的重要解决方式。

CloudWatch

使用CLI工具。

要利用Web控制台创建警报机制。我们可能须要面临大量繁的工作，特别是在设置众多内容类似的警报信息时。由于我们无法直接“克隆”现有警报并仅对当中一小部分作出改动。在这样的情况下，利用CLI工具实现脚本化效果可以帮助各位节约大量宝贵时间。

使用免费监測指标。

CloudWatch监控工具以免费方式提供各类监測指标（包含传输带宽、CPU使用率等等），并且用户可以获取到最多两周的历史数据。有鉴于此，我们根本用不着花钱购置自己的工具来实现系统监控。但假设大家须要超过两周的历史数据记录。那没办法。仅仅能使用第三方或者自行开发的监控方案了。

使用自己定义监測指标。

假设大家希望监控免费指标之外的其他项目。则能够将自己的定制指标信息发送至CloudWatch。并使用相关警报与图形功能。

这不仅能够用于追踪诸如磁盘空间使用量等状况，同一时候也能够依据实际需求自行设定应用程序监測方向。

感兴趣的朋友能够点击此处查看AWS提供的公布自己定义监測指标页面。

使用具体监測机制。

这项服务每月每实例的使用成本约为3.5美元。但其提供的丰富额外信息绝对可以值回票价。1分钟的细化监測甚至好过5分钟的粗放查看。大家可以借此了解到某次时长5分钟的崩溃究竟是因何而起，同一时候以很明白的方式将其以1分钟图表的方式显示出来。

或许这项功能并不适用于每闰用户，但就我个人而言、它确保帮我弄清了不少原本神奇的疑难杂症。

自己主动伸缩

利用INSUFFICIENT_DATA以及ALARM进行规模缩减。

对于规模缩减操作而言，大家须要确保可以在不具备指标数据甚至触发机制本身出现故障时仍能正常实现规模缩减。

举例来说，假设大家的某款应用程序平时始终处于低流量状态，但突然迎来了流量峰值。大家肯定希望其可以在峰值结束且流量中止后将规模恢复至原有水平。假设没有流量作为參考。大家可以使用INSUFFICIENT_DATA来替代ALARM作为低流量阈值情况下的规模缩减运行手段。

使用ELB执行状态检查代替EC2执行状态检查。

在创建扩展组时系统会提供这样一个配置选项。大家可以指定是否使用标准的EC2检查机制（当该实例接入网络时）。或者使用自己的ELB执行状态检查机制。ELB执行状态检查机制可以提供更出色的灵活性。假设大家的执行状态检查机制发生问题，那么该实例将被移出负载均衡池，在这样的情况下大家当然希望可以通过自己主动伸缩中止该实例并创建新的实例加以替代。

假设大家没有利用ELB检查设置出扩展组。那么上述功能将无法实现。AWS在说明文档其中就加入执行状态检查机制作出了详尽说明。感兴趣的朋友可以点击此处进行查看。

仅仅使用ELB预先配置的可用区。

假设大家将扩展组加入到多个可用区内。请确保自己的ELB配置可以正确使用所有可用区。否则在容量发生向上扩展时，负载均衡器将无法正确识别出这些可用区。

不要在同一个组内使用多个扩展触发器。

假设大家在同一个自己主动伸缩组内选择了多种用于触发规模调整的CloudWatch警报机制，那么它们可能无法如各位的预期那样正常起效。

举例来说。假设大家加入的触发器会在CPU使用率过高或者入站网络流量强度过大时进行向上扩展，并在情况相反时对规模进行缩减。但在使用过程中，我们往往会发现CPU使用率持续添加，但入站网络流量却保持不变。这时高CPU负载触发器会进行容量扩展操作，但低入站流量警报却会马上触发规模缩减操作。依据各自运行周期的不同。二者之间的作用非常可能会被抵消，导致问题无法得到切实解决。因此，假设大家希望使用多种触发器方案，请务必选择多自己主动伸缩组的方式。

IAM

使用IAM角色。

不要面向应用程序创建用户，而尽可能使用IAM角色。它们可以简化全部相关工作，并保证业务环境的安全水平。创建应用程序用户仅仅会带来故障点（假设有人不小心删除了API密钥），并且令管理工作更加难以完毕。

用户能够拥有多个API密钥。

假设某些员工在同一时候处理多个项目，又或者大家希望可以利用一次性密钥对某些内容进行測试，那么这样的方式将很有用。我们全然不必操心真正的密钥被泄露出去。

IAM用户能够使用多因素身份验证。请善加利用！

启用多因素验证机制可以为我们的IAM用户提供额外的安全层。我们的主账户肯定应该引入这项机制，面仅仅要有可能、普通IAM用户亦应当享受到由此带来的保障。

Route53

使用ALIAS（即别名）记录。

ALIAS记录会将我们的记录组直接链接到特定AWS资源处（即能够将某个域映射至某个S3存储桶），但其关键在于我们用不着为了ALIAS查找而支付费用。因此与CNAME这类付费机制不同，ALIAS记录不会添加不论什么额外成本。另外。与CNAME不同，大家能够在自己的区索引其中使用ALIAS。感兴趣的朋友能够点击此处查看AWS官方提供的ALIAS资源记录集创建说明页面。

弹性MapReduce

在S3中为Hive结果指定一个文件夹。

假设大家打算利用Hive将结果输出至S3。则必须在存储桶内为其指定一个文件夹——而非存储桶根文件夹。否则我们非常可能遭遇NullPointerException，并且全然找不到引发这一问题的理由。