|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
If you have more than one AMI you want to sell, this section can help you decide whether to create one or multiple DevPay products to cover your AMIs.
To recap the basic process for creating a paid AMI: you register a DevPay product, receive a product code, and associate the product code with your AMI (for more information, see Process for Creating and Using Paid AMIs). Your customers must sign up for your product before they can launch instances of your AMI.
You can associate the product code with multiple AMIs, but each AMI can have only one product code. After an AMI is associated with your product code, it sells for the price you set when you registered the DevPay product. For information about what happens to the product code when you rebundle an AMI, see Inheriting the Product Code of your Paid AMI.
What if you have more than one AMI to sell? For example, let's say you have two Linux/UNIX AMIs and three Windows AMIs to sell. You have three options (also illustrated in the following figure):
Option 1—Register a single DevPay product that covers them all
Option 2—Register a separate DevPay product for each
Option 3—Do something in between
For example, you could register one DevPay product for the Linux/UNIX AMIs and another for the Windows AMIs.
What's the best path to follow? The answer depends on your needs. The following sections describe factors to consider as you decide how many DevPay products to create for your multiple AMIs.
If you charge a monthly fee, that single fee covers the customer's access to all the different AMIs covered by the product. For example, if the product covers five different types of AMIs (two that use Linux/UNIX and three that use Windows), the customer can use all five types for the one monthly fee (plus any usage-based charges). The customer doesn't pay the monthly fee for each type of AMI. This also applies if your product covers multiple AMIs all of the same type. For example, you could assign a single product code to 10 Linux/UNIX AMIs, and a customer could use all 10 for the single monthly fee (plus the usage-based charges). The customer doesn't pay the monthly fee for each of the 10 AMIs.
Amazon EC2 charges different prices depending on the region, environment, instance type, etc. (for more information, go to the Amazon EC2 detail page.) Likewise, you can specify which regions, environments, instance types, etc., your product covers, and charge your customers different prices based on those variables. If you want to vary a specific instance type's hourly charge for one AMI versus another, then you need more than one DevPay product. For example, if you want to charge $0.25 per small instance-hour for one Linux/Unix AMI, but $0.35 per small instance-hour for another, then you need a separate DevPay product for each AMI.
Before customers can launch instances of a paid AMI, they must sign up for the DevPay product that covers that AMI. If you decide to have a separate DevPay product for each AMI you sell, your customers must go through the purchase process for each AMI they use. You need to decide if this is the customer experience you want. To see an example of the customer purchase experience, see Appendix: The Customer Purchase Experience.
You get the benefit of the tiered pricing structure that AWS uses for data transfer out (for more information, see The Cost of Tiered Usage Types). AWS applies the tiered pricing to the usage across all customers of a single DevPay product. Therefore, the more AMIs a single DevPay product covers, the easier it is for that product to reach the usage levels where you pay a lower cost for data transfer out.
DevPay provides you usage data per product, but not per AMI (for more information, see Usage Report). If it's important for you to have usage data per AMI, you can register a different DevPay product for each AMI. However, we recommend you consider the other customer-impacting factors discussed in this section before choosing this path.
You can have multiple versions of a DevPay product. For example, you could have a regular version and a more expensive support version that includes customer support that you provide. In this case you would register a separate DevPay product for each version.
You can't automatically upgrade or migrate a customer between DevPay products. Instead, the customer must cancel the subscription to the first (we refund any unused portion of the monthly fee), and then go through the purchase process for the second. No monthly fees, account information, or usage information can be transferred between the two products.