【摘要】“常在河边走，哪有不湿鞋！”本文介绍当遇到AWS EC2维护需求时，需要注意的事项。世事难预料，Amazon偶尔也会有重启服务器或者实例的需求，比如给系统重要软件的更新和为系统打安全补丁等等。这种情况下，我们有可能会收到来自Amazon的操作请求，这里是一个例子：

应对方法：
1. 确保你的启动脚本在重启后正确运行
首先放轻松，Take it easy！不要感觉有太多压力，先确信一点，你的所有的Script脚本（或者Chef recipes）能够完全正确的运行。大部分AWS自带的脚本默认都是开机自动运行的，然而，一些自己的脚本或者第三方的脚本往往并不是这样的。我们可以为这些脚本设置一些环境变量，检查重启的状态，如果遇到这种情况，脚本将不会被二次运行或者脚本必须执行。
如：

当你把上面的脚本放到你的bash脚本中，它将检查$RS_REBOOT变量的状态，如果为True，脚本将被跳过执行。

2. 备份
接下来的事情是检查我们修改过的配置文件的修改情况，可以通过备份过的脚本或者配置文件进行恢复。可能的话我们一般推荐将这些配置写成脚本放到自启动脚本或者Chef Recipes中。这样做的原因是如果写成脚本化，当一个实例被重启或者relaunch时自定义的一些配置将会通过脚本重新修改过来，这样就不用担心是否已经将文件备份到某处了。
下面是一个简单的例子，修改AWS EC2 instance的Timezone：

脚本很简单，我们可以传递一个值给timezone，然后每次脚本运行的时候会正确的设置timezone。

下面的例子是通过sed编辑配置文件：

脚本用来更新实例的hostname，这样就不需要再ssh登陆进来，再去手动编辑 /etc/hosts了，并且有了脚本，我们也不用备份/etc/hosts文件，再通过文件进行恢复了。

EBS volumes
一个有用的备份操作就是你有运行中的实例上的一些或者全部的EBS volumes快照（snapshots），你可以手动做snapshot或者使用EBS工具，对于重点的实例建议连续“Continuous”的快照备份脚本，每天定时运行。

3. 主动出击，自己重启实例
如果上述两点都已经注意到了，开机脚本和EBS备份都已经完备，那么你应该已经做好了重启实例的准备工作。这里注意的一点是在业务不受影像的前提下，比如Instance是在ELB后面。或者你担心Amazon的例行维护重启实例在启动时不是很完整，你可以再手动重启一遍。

relaunch操作会给你一个新的实例，意味着你从硬件资源池中获取了新的EC2 Instance ID。这是一个好的选项（在99%的情况下，我们通常推荐使用re-launch而不是reboot）。原因是这样我们可能在新的硬件资源上获得一个新的实例，而不必再遭受AWS-scheduled重启操作。

注意：
有预见性是重要的！因为当实例被rebooted/relaunched 你无法控制。如果AWS计划在几个小时候重启硬件，恰好你的生产环境运行在上面你会很被动。作为苦逼的SA，在短时间内你需要找到解决办法，而你又必须要面对这个事实。如果你提前做好的准备，面对这样的例行维护时就不会慌张了。

本文固定链接: https://www.sudops.com/howto-aws-ec2-scheduled-maintenance.html | 运维·速度