Organizations, Consolidated Billing
You can use AWS Organizations to link all your accounts, and then use Consolidated Billing to utilize unused RI price with Instances of the same type in other accounts.
You have multiple AWS Accounts and additional unused reserved instances in the main production account. You have deployed On-Demand instances in the Test & Dev Account. How can you reduce your total EC2 costs?
- Step one, Create AWS Organizations
- Use Consolidated Billing to link the Accounts.
EC2 Costs
Detailed monitoring and use of Elastic Load Balancers will increase your EC2 Instances costs.
Spot instance pricing
See here for the tables.
If you terminate your spot instance, you are charged with the same policy as on-demand (though different rate): Linux, for second; Windows, for full hour even if you use partial hour.
If EC2 terminate your spot instance, if it’s in spot block, no charge at all; if not in spot block, for Linux you are charged by second, for windows you are not charged for the partial hour.
Scheduled Reserved Instances
Scheduled Reserved Instances (Scheduled Instances) enable you to purchase capacity reservations that recur on a daily, weekly, or monthly basis, with a specified start time and duration, for a one-year term.
DynamoDB Pricing
DynamoDB charges for *reading, writing, and storing data *in your DynamoDB tables, along with any optional features you choose to enable.
DynamoDB has two capacity modes and those come with specific billing options for processing reads and writes on your tables: on-demand and provisioned.
on-demand capacity mode
With on-demand capacity mode, DynamoDB charges you for the data reads and writes your application performs on your tables. You do not need to specify how much read and write throughput you expect your application to perform because DynamoDB instantly accommodates your workloads as they ramp up or down.
provisioned capacity mode
With provisioned capacity mode, you specify the number of reads and writes per second that you expect your application to require.
Pricing Terms
Read request unit: RCU
API calls to read data from your table are billed in read request units. DynamoDB read requests can be either strongly consistent, eventually consistent, or transactional. A strongly consistent read request of up to 4 KB requires one read request unit. For items larger than 4 KB, additional read request units are required. For items up to 4 KB in size, an eventually consistent read request requires one-half read request unit, and a transactional read request requires two read request units. For example, a strongly consistent read request of an 8 KB item requires two read request units, an eventually consistent read of an 8 KB item requires one read request unit, and a transactional read of an 8 KB item requires four read request units. See Read Consistency for more details.
Write request unit: WCU
API calls to write data to your table are billed in write request units. A standard write request unit can write an item up to 1 KB. For items larger than 1 KB, additional write request units are required. A transactional write requires two write request units. For example, a write request of a 1 KB item requires one write request unit, a write request of a 3 KB item requires three write request units, and a transactional write request of a 3 KB item requires six write request units.
Replicated write request unit: rWCU
hen using DynamoDB global tables, your data is written automatically to multiple AWS Regions of your choice. Each write occurs in the local Region as well as the replicated Regions.
Streams read request unit:
Each GetRecords API call to DynamoDB Streams is a streams read request unit. Each streams read request unit can return up to 1 MB of data.
Transactional read/write requests:
In DynamoDB, a transactional read or write differs from a standard read or write because it guarantees all operations contained in a single transaction set succeed or fail as a set.