Sorry for the delay in my response - been caught up teaching and just jumped across Australia today.
The 1GiB is perhaps a little too small - especially on an m1.small host with no other instance store disks. 10GiB is listed as the maximum for S3 baked instances... but my rushed testing since Sunday found that the bundling failed for this using our scripts (ie, I updated the manifest file).
if you're using the S3 backed image on anything larger than an m1.small then you may have additional ephemeral/instance-store disks that you can map (on instance launch), format and mount to their full size, but the root disk is still limited to being with the 10 GiB upper bound.
If you're finding IO times on EBS are an issue, reach out to support for them to have a look; otherwise, have a look at Provisioned IOPs. It's worth noting that after a certain amount of I/O, turning on PIOPs can be cheaper than not having it turned on - so if you're doing that level of I/O its worth looking closer at if disk IO is the issue. Another option you have is to use EBS for your root file system, but use (a set of) instance store disks for your application to serve from. You may also want to RAID 1 mirror multiple instance store disks together to guard against failure of individual instance store disks (and should any fail, schedule the instance to be terminated and re-provisioned at your convenience).
Creating your own AMI should be as easy as checking out from github (https://github.com/andsens/bootstrap-vz), setting your environment variables up with a secret key, accesss key - and for an S3 backed AMi you currently also need a certificate (see IAM) - edit the manifest file (manifests/ec2-s3-....manifest) to change the size of the disk, and then run bootstrap-vz manifests/ec2-s3-....manifest)
On 11/02/2014 1:01 AM, Alistair Prestidge wrote: