Billing when changing a running Elastic Capacity on Demand request
Ensure that you understand the implications to billing before you decide to change a running Elastic Capacity on Demand (CoD) request.
When you issue a change request, the days in the running request are not preserved; however, the time in the current resource day is carried forward from the running request. It is important to understand that the resource days that remain in a request are decremented at the start of each day. Therefore, the number of resource days billed is incremented at the start of each day.
If the change request decreases the amount of resources in the running request, the remainder of the current resource day is forfeited for each of the resources that are being canceled. No credit is given for any partial resource days that are forfeited. If the change request increases the amount of resources in the running request, a charge for the additional resources for the time that remains in the current resource day is immediately applied. That charge is calculated as additional resources multiplied by the quantity (time that remains in the current resource day rounded up to the whole hour and divided by 24). The result is rounded up to whole resource days. The usual charge for any requested days in the change request applies.
The number of resource days in the Elastic CoD enablement is calculated separately from the number of resource days that are billed. When an Elastic CoD request is started, the number of enabled resource days is reduced by the number of requested resource days (number of requested resources multiplied by the number of requested days). When a running Elastic CoD request is changed, the number of enabled resource days is increased by the number of remaining resource days in the running request, then reduced by the number of requested resource days in the change request. If the change request increases the number of resources, the number of enabled resource days is also reduced by the number of resource days that are charged for the additional resources for the time in the current resource day.
If you decide, within the same day, to again activate the Elastic CoD processors, such as during a test period, the implications to billing are slightly different. The 24-hour test period starts when the first Elastic CoD request is made. During the 24-hour test period that your server is powered on, a record is kept of the maximum number of Elastic CoD processors or memory requested when you make Elastic CoD activation or change requests. Therefore, as the testing reactivation occurs, you can start and stop, or change, Elastic CoD requests repeatedly. Any subsequent requests during the same 24-hour period for the same or fewer resources are not charged. Requests that are made for more resources result in a pro-rated charge for the excess resources. This new, higher level of resources becomes the maximum resource amount for the 24-hour period, and subsequent requests during the same 24-hour period are not charged for resources up to this new maximum amount. For information about testing your Elastic CoD activations, see Testing your Elastic Capacity on demand activations.
Examples: Changing a running Elastic CoD request
At 9:00 a.m. on Monday, you start a new request for 5 processors for 1 day. The result is:
- 24 hours remain in current processor day
- 1 day plus 0 hours until request expires
- Charge for 5 processor days (5 processors multiplied by 1 day)
- Enablement reduced by 5 processor days
At 11:00 a.m. on Monday, you change the request to 5 processors for 2 days. The result is:
- 22 hours remain in current processor day
- 2 days plus 22 hours until request expires
- No additional charge
- Enablement reduced by 10 processor days (5 processors multiplied by 2 days)
At 3:00 p.m. on Monday, you change the request to 10 processors for 2 days. The result is:
- 18 hours remain in current processor day
- 2 days + 18 hours until request expires
- Charge for 4 processor days (5 additional processors multiplied by 18 hours in current processor day divided by 24 equals 3.75, which is then rounded up to 4)
- Enablement increase by the 10 processor days in the running request, then reduced by 24 processor days (10 processors multiplied by 2 days plus 4 processor days charged for the hours in the current processor day)
At 5:00 p.m. on Monday, you change the request to 2 processors for 2 days. The result is:
- 16 hours remain in current processor day
- 2 days plus 16 hours until request expires
- No charge and no credit for the 8 canceled processors
- Enablement increased by the 20 processor days in the running request, then reduced by 4 processor days (2 processors multiplied by 2 days)
At 7:00 p.m. on Monday, you change the request to 2 processors for 1 day. The result is:
- 14 hours remain in current processor day
- 1 day plus 14 hours until request expires
- No charge and no credit
- Enablement increased by the 4 processor days in the running request, then reduced by 2 processor days (2 processors multiplied by 1 day)
At 9:00 a.m. on Tuesday, the request is still active. The result is:
- Start of new processor day
- 24 hours remain in current processor day
- 1 day plus 0 hours until request expires
- Charge for 2 processor days
- No change to enablement
At 9:00 a.m. on Wednesday, the request expires. The result is:
- No charge or credit
- No change to enablement
At 10:00 a.m. on Wednesday, you start a new request for 5 processors for 2 days. The result is:
- 24 hours remain in current processor day
- Charge for 5 processor days
- Enablement reduced by 10 processor days
