Costs
In my experience AWS are pretty transparent about pricing and the "pay for what you use" principle seems to be consistent. "Transparent" doesn't always mean "easy to figure out" though, I agree.
The simplest way to pin down the real costs is to put the AMIs on an otherwise unused account and the cost incurred each day will be clear. I have a spare account that has run for years with no activity and has been billed nothing, so I'll put a clone of the AMIs up there and let you know how the billing works out. I haven't worked with the AWS Marketplace where you have the current AMIs publicised, but I believe listings are free for open source projects.
My understanding of the costing would be:
For the person hosting the public AMI:
- Storage cost for the actual bits of the AMI. For an EBS backed instance this is the cost of the root volume storage at 0.10 per GB-month. Note that empty blocks aren't counted so you are only charged for the actual storage allocated not the maximum volume size, so about 3 to 4 Gb of the 10Gb volume. So at 0.10 per GB-month it should be less than a dollar per month. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ComponentsAMIs.html
For the end user:
- Running costs for the instance. This depends on instance type but is easy to calculate per hour. The default micro instance is currently $0.020 per Hour or about $15 per month (and would be free for the first 12 months if you qualify)
- Storage costs for the instance data in EBS. This is currently 0.10 per GB-month.
- Storage costs for any snapshots of the EBS volume at $0.095 per GB-month.
Given the default EBS boot volume is only 10Gb I wouldn't expect cost for the end user to be more than $20 per month even with a couple of rolling backups of the instance.
Effect of Withdrawing the AMI on Running Instances
Just to be clear, the AMI is just a template for firing up an instance. Once the instance is launched it has no further connection with the AMI and deleting the AMI won't affect it.
Of course, if you want to go back and launch another base instance you won't be able to do that if the AMI no longer exists, so
wardmundy 's advice is sound: create an AMI of your own.
I would suggest this as a matter of course anyway. You don't want to have to rebuild your configuration from scratch if there is a problem. Each time I do an update to the system (say the security patches) I create a new AMI and delete the oldest. That way I could recover from a disaster (or a misconfiguration for that matter) by relaunching the latest version.