我们通过Cloudformation创建了Stack之后，如果发生需求改变，那么需要进行修改。Update Stack的操作其实很容易，不过有几点需要注意。
- 进行Update操作之前，请执行stack drift的操作，以确保一致性。
- 进行Update操作的时候，请查阅相关的resource的属性，判断是否会导致某些服务中断
- 有些属性，例如EC2 的Public IP，如果没有绑定EIP，那么重启之后会变化，这些因素需要考虑
- 我们可以通过Stack Policy来限制对某些Resource进行修改
- 我们可以通过Change set来预览我们的改变。
下面通过一个例子说明
首先我们创建一个演示的LAMP 的 Cloudformation stack，他会创建一个EC2 实例和一个SG
输入 Parameters 的值
值得一提的是，他的Instance的Resource的名字叫做WebServerInstance，这个下一步会用到
在Stack policy的设定里面，我们输入下面的Policy 。 这个Policy的目的是允许修改所有的资源，除了WebServerInstance。
提交之后，我们的Stack就创建好了
接下来，我们试试修改，点击 Update
我们有三个选项， Use Current template 只能修改Parameters的值，后面两个可以修改整个Template
作为测试，我修改了我的InstanceType 从 t2.micro 到 t2.small （ 如果我的stack policy工作的话，这里是禁止修改的，因此会导致更新失败，而回滚到原先状态）
下一步，注意看他的Replacement 显示为 Conditonal
这个代表的是他的Update Behavior。具体有三种
我们如何判断一个resource的修改是否会造成服务中断呢？一个是常识，另外我们还可以查看对应的CF的帮助文档，每一个属性都会告知 Update requires的类型是什么
最后我们提交Update，等待1分钟后，发现他更新失败（意料之中）。错误提示为我的stack policy 否决了对EC2的修改
最后，我们再来看看Change set。这个功能允许我们提交一个update的请求，然后可以查看对应的变化，然后才真正的提交执行。上面的例子我并没有手动的创建change set，而是直接进行的Update，即便如此，他也自动创建了一个Change Set。如果我们的改动成功了，那么这里会自动清空。因为change set是把我们的改动和初始文件进行对比，所以如果我们有多个change set，只要其中一个成功执行了，其他的change set所执向的初始文件就会自动作废了，也就是所有的change set都会清空。当然上面我们的update因为 stack policy被拒绝了，因此他默认产生的change set依然在这里
点进去看看
Changes 会显示哪些resource 做了改动
Input是 显示我输入的Parameter 参数
Template就是当前的模板
JSON change 显示具体哪些东西做了改变，以及他们可能会造成中断，他很智能的把相关的Ref 调用的资源以及影响都显示出来
然后确认无误之后，就可以选择执行或者删除
我再进行一次Update的操作，这次我修改了EC2 的实例，同时也修改了我的stack policy。注意 AWS不允许删除stack policy，因此如果需要移除保护，我们只能在配置文件里面设置允许所有操作。
提交之后，成功执行了Update
查看EC2 可以看见类型变成了t2.small, instance id，avaiable zone等等都没变化，但是public IP自动变化了，因为他没有绑定EIP，所以当实例关机，再开机之后public ip也自动变了，尽管这个并没有在我们的update的设置之中。
