假期结束了，之前学过的aws core service的内容有点生疏了，姑且整理和回顾一下。还是按照以往的经验，想到什么就记录什么，尽量不抄袭文档，但是文中会涉及到大量的其他文档，感兴趣的可以一一点开学习
利用业余时间更新，慢慢写吧
参考资料：
常见问题汇总support 知识中心ec2 常见问题 ec2究竟是什么？
接触过云的用户肯定知道弹性计算服务，ec2就是aws的弹性计算产品，全称elastic compute cloud。ec2实际上担负起了aws产品体系中计算资源弹性化的使命（即按需使用，按量付费），用户可以自由的按照需求使用不同性能（x核xG）的机器，这都是老生常谈的东西，在ec2文档介绍的很详细，我们来点别的。
谈到ec2，就必须涉及到ec2的虚拟化技术，这是aws区别于其他云厂商的关键点，这篇《Amazon EC2 虚拟化技术演进：从 Xen 到 Nitro 》以及这篇blog分别深入的回顾了aws虚拟化技术的发展，顺理成章的我们就能够理解为什么ec2产品这么多种实例类型有何区别，为什么t2类型的实例变成t3之后会启动失败等等
可以看到aws经过了4种虚拟化技术的发展，参考虚拟化技术的优缺
全模拟技术。这种虚拟化方式能支持未修改的客户机操作系统，但速度会严重下降。典型产品是VMware 在1986年发布的虚拟化产品。AWS 并没有采用这种虚拟化技术基于Xen的半虚拟化技术（Paravirtualization，PV）。PV 要求修改客户机内核和驱动。EC2第一个采用半虚拟化的实例类型是 m1.small。基于Xen和CPU硬件的全虚拟化技术（Hardware-assisted virtualization，HVM）。采用Xen HVM 技术的虚拟机运行在具有CPU和内存（VT-x）硬件虚拟化能力的处理器上，并使用半虚拟化驱动程序用于网络和存储设备。HVM 3.0 中尚未实现中断和定时器半虚拟化，但在4.0中已有改善。AWS Nitro技术，这是AWS 研发的一种新虚拟化平台。
目前最新型的实例采用的是nitro技术，其实简单来说，最终的目的就是如何能够最大限度的利用好硬件的性能，让操作系统运行的更加快流畅，降低网络和存储性能的损耗
从这篇Xen虚拟化技术中PV和HVM的区别，基于传统硬件结构的计算机通过驱动的方式实现了网络和存储等外部设备的虚拟化（XEN），但是会损耗性能，之后的芯片通过引入interl的NT-x AMD-V，使用HVM技术避免了这一问题。而aws的nitro则更进一步，通过定制化的硬件，硬件上加装专用的磁盘和网卡等，进一步优化了硬件和软件运行的性能。除此之外，由于将网络和存储设备等单独分离出来，也进一步实现了不同资源的隔离，现在你可以自由的组合不同类型的计算、存储和网络资源了。
众所周知的是，云厂商大都有统一管理的数据中心，我们所使用的产品就是基于这些数据中心的硬件运行的，ec2实际上和我们在本地启动的虚拟机没有什么本质的不同，只不过aws做的更加彻底，想象一下机房中的场景，一个个机房，里面摆放着一个个机柜，机柜上放着一个个刀片机，不同的机房承担这不同产品的服务，通过复杂的线路相互连接。这里aws应该配套了自己的系统级软件来完成硬件资源的虚拟化和调度，这个就不深入讨论了（我也不懂，哈哈）
现在，让我们假设我们所使用的ec2所在的机器出现了异常，即ec2实例的健康检查出现了问题，如果是系统检查失败，那八成是因为aws的硬件异常，这个时候不要慌，当你重新启动或者再起一台新实例的时候，ec2会自动在另一个物理位置创建实例，原来的硬件问题可以慢慢解决。当aws通知需要对某些机器进行维护和升级时，往往会向用户发送计划时间，这个时候我们需要在业务空闲的时候，手动停起机器，避免不必要的损失。让我们在开动一下脑洞，既然aws将硬件虚拟化了，那我们所使用的资源都可以自由地组合了，那为什么有时候启动新实例的时候会提示容量不足呢？我猜测应该是，不同用户对机器的需求有差异，性能强悍的机器可能用的人不是很多，所以可能启动的时候这个区域的剩余机器刚好就不够，所以才会报错。说到这里，我猜测，aws设置会按照用户的需求动态的调整ec2实例的数量，毕竟计算资源都虚拟化了，那我把一个4核8g的机器，拆分成4个1核2g的机器给用户使用，有什么不行的呢？
这也是为什么aws为我们提供了置放群组的选项，说白了就是ec2实例要不要启动在近一点的地方，可以使用三种置放策略创建置放群组：包括集群、分区以及分布三种策略，让用户在性能核风险之间自己权衡。
ec2可以说是大部分aws服务的基础，为了管理ec2，aws必然通过软硬件的方式为ec2植入了大量的监控，但是这却不会影响ec2的性能。比如cloudwatch指标，cloudtrail日志，iam权限和实例的metadata等，这些对于用户来说是完全透明的，我们只需要使用ec2即可，将ec2的管理和维护交给aws来做，这也是云服务的初衷
实例类型的问题ec2的实例类性太多了，在官方文档中对不同类型的实例进行了分类，对应不同的用途，例如通用类型，计算优化，存储优化等。在每个大类下，又分为不同的小类，如下的通用类型
可以看到包括实例的简介，性能，能够突增，有哪些特性等等，还有支持的架构，底层的虚拟化技术，这里有一篇比较t3，t3a和t4g机器的blog，大家可以感受一下，不要小看这些类型的差异，我们以后使用ec2产品种出现的各种问题很有可能就是实例类型选取不当导致的，举几个例子：
实例ebs明明还有剩余性能，为什么达不到（可能是用了不具备ebs优化的实例，发生了带宽的限制）为什么t2升级t3实例失败（t2不支持nvme存储和ena增强网络，如果不是Amazon linux的ami可需要手动安装驱动）为什么我启动新实例挂载了新的根卷但是检查失败（如果实例类型只支持arm，那么x86的卷就起不来）为什么我重启之后数据没了（可能是使用了实力存储卷作为根卷，此外只有以下实例类型支持将实例存储卷作为根设备：C3、D2、G2、I2、M3 和 R3 ）
以上仅仅是抛砖引玉，强调一下实例类性的重要性，我们在业务变动或者别的场景中，也会需要改变实例类性的需要，这个时候要慎重考虑兼容性，性能和费用的问题然后再决断，有条件的可以咨询support人员
实例创建和连接我们现在开启了一台新实例，现在思考三个问题
我们如何创建新实例（配置了什么东西）？实例启动过程发生了什么？我们如何连接ec2，并正式上面的两点？
看看第一个问题，就是这里的第一步，实际上要选择的东西非常多
