我正在尝试创build一个EC2大型实例。 AWS声称，如果我去大型实例，我将获得850 GB的实例存储。 我将VMconfiguration为具有100 GB的根卷大小。 但是，当我启动EC2 VM和ssh时，它只显示了8 GB的存储空间（df -h）。 我如何使用整个850 GB的。 你能否build议我在哪里做错了。 谢谢
我在EC2 Web控制台中有数百个实例。 有些关机。 我可以看到它们是在几个月或几年前创build的。 他们似乎被遗弃和遗忘了一段时间，但很难说是否终止他们是安全的。 例如，他们可能是一些旧的备份，有人可能已经迁移到新的实例负载，并保留了几个星期作为预防措施，等等… 我们最终保留大部分，因为这是最安全的select。 当实例closures （但未终止） 时，我们仍在为EBS卷支付费用 。 许多未使用的实例（EBS是每月每TB 140美元）随着时间的推移可能会boost价格。 所以我想做一些清理。 我在想，如果我能findclosures实例的时间，这将是一个很好的指示，如何“放弃”它。 我怎样才能find一个实例上次关机？
可能重复： 什么是自动备份EC2实例最简单的方法？ 我有一个EBS支持的Amazon EC2实例。 我想创build一个每日备份计划，并保留一周的每日备份，以及一些较旧的图像（从2,3,4周前）。 我不介意使用快照机制即时创build备份，但是我想要一个简单的包装来为我pipe理它。 设置这个最简单的方法是什么？ 对于微观实例，这会花费多less钱？
我有两个系统，一个运行Ubuntu 11.04，一个运行10.04 LTS。 两台机器的相同configuration产生不同的结果。 10.04LTS机器无法find我的AWS凭证文件。 11.04 export | grep EC2 declare -x EC2_CERT="/home/jdw/.ec2/cert-PJU5MW2PCN24SKPOIVFTWCMBUXWWZO7U.pem" declare -x EC2_HOME="/opt/ec2-ami-tools-1.3-66634" declare -x EC2_PRIVATE_KEY="/home/jdw/.ec2/pk-PJU5MW2PCN24SKPOIVFTWCMBUXWWZO7U.pem" ls -al /home/jdw/.ec2/ total 16 drwxr-xr-x 2 jdw jdw 4096 2011-08-18 13:31 . drwxr-xr-x 58 jdw jdw 4096 2011-09-23 10:24 .. -rw-r–r– 1 jdw jdw 916 2011-08-18 13:30 cert-PJU5MW2PCN24SKPOIVFTWCMBUXWWZO7U.pem -rw-r–r– 1 jdw jdw 928 2011-08-18 13:30 […]
我们有大量的AWS EC2上托pipe的Ubuntu服务器。 许多这些服务器很less被访问，为了节约成本，我们现在想将这些服务器移到我们的本地站点，并在Amazon上终止它们。 大多数服务器都支持EBS，我们使用pipe理控制台为这些服务器创build了AMI映像。 我希望下载现有的AMI，然后使用这些映像在本地构build新的服务器，这样我们就不必从头重新安装应用程序堆栈和configuration。 1）这可能吗？ 2）如何去下载这个AMI？ （我希望能够从pipe理控制台以某种方式进行操作）。3）AMI如何改变以便能够用于安装？ 我如何在本地运行Ubuntu EC2 AMI映像？ 似乎提出了一个答案，但它链接到的文章包含不再可访问的重要链接。 这似乎也表明了一个相当复杂的过程。 https://forums.aws.amazon.com/message.jspa?messageID=204881似乎暗示有可能做到这一点，但并没有解释如何实际下载图像，而https：// stackoverflow.com/questions/5145286/boot-ec2-ebs-volume-locally表明这是不可能的。
我想尽可能便宜地设置厨师服务器，同时留出足够的空间来运行而不会崩溃。 我在这个主题上发现的唯一一篇文章警告说，由于内存不足，RabbitMQ会在微型实例上崩溃。 问题是：考虑到我的应用程序中没有使用CouchDB或RabbitMQ，所以最便宜的EC2实例可以可靠地运行厨师服务器，所以可能必须在同一个实例上专门为厨师服务器设置它们。
在不使用第三方云configuration服务的情况下，使用EC2进行configurationpipe理的主题是什么常见的模式/策略或白皮书？ 具体来说就是如何在启动时configuration和configuration新的实例，代码部署策略等等。
在AWS上，我设法创build了一个修改后的Ubuntu 12.04 LTS amd64的AMI。 我已经添加了很多包和我们自己的代码和文件。 云初始化还在那里，我肯定应该留下来。 然而，在我用于为AMI创build快照的原始卷中启用它之后，它通过在运行时重新禁用root来破坏我的自动化。 文件/usr/share/pyshared/cloudinit/CloudConfig/cc_ssh.py似乎与此连接。 由于我在Python编程方面没有经验，所以我不知道它调用的一些函数是什么，所以我不能真正看到这个脚本正在做什么。 我可以添加一些我自己的init脚本，以便在某个地方运行，以便撤销并重新启用root。 有没有一种方法，由云初始化标准化或制裁，设置一个标志，以表明禁用根login不应该做？ 或者我应该只是推出我自己的解决scheme（后来初始化放回我自己的/root/.ssh/authorized_keys文件）。 我也看到这个脚本正在删除旧的主机密钥并重新生成新的主机密钥。 这是我想保留的东西（因此我不需要自己做）。 我还将SSH侦听端口号更改为22以外的数字（并且安全组设置为仅允许从我自己的IP访问该端口）。 那么多没有改变。 这很好。
我有一个AWS EC2实例，并希望拒绝访问端口80上的单个IP地址（一个坏的机器人）。 AWS控制台似乎只支持“允许”规则。 如何拒绝一个单一的IP地址？
在亚马逊宣布新的基于EBS的AMI后 ，我想知道是否可以创build不基于现有Fedora / Windows AMI的AMI。 该文件说： 最简单的方法包括从现有的公共AMI开始并根据您的要求进行修改。 这适用于Amazon EBS支持的和Amazon S3支持的AMI，在“从现有的AMI开始”中进行了描述。 另一种方法是在独立的机器上或通过环回安装的空文件系统上构build新的安装。 这仅适用于Amazon S3支持的AMI，需要从头开始构build操作系统安装。 这听起来像所有未来的AMI必须基于现有的AMI，但这将是非常有限的。 我是否正确理解这一点，或者是否有其他方法来创build不基于现有AMI的方法？ 我会对创buildUbuntu AMI感兴趣。