AWS Metrics & Billing continued:
AWS Metrics cited so far included the following:
CPUCreditUsage – This metric is available at a 5 minute frequency and are available as counts. This metric identifies the amount of time during which the physical CPUs were used for processing instructions by virtual CPUs allocated to the instance.
Multiplying the count with the duration we get the total instance-hours for that instance.
CPUCreditBalance – This is the number of CPU credits that an instance has accumulated. This metric is used to determine how long an instance can burst beyond its baseline performance
Like CPUCreditUsage – This metric is available at a 5 minute frequency and are available as counts. Multiplying the count with the duration we get the total instance-hours of credit for that instance.
CPUUtilization – This is the percentage of allocated EC2 compute units that are currently in use on the instance. This metric identifies the processing power required to run an application upon a selected instance. It is measured in percents.
This data can be filtered based on the InstanceID that is specific to the identified instance or InstanceType that encompasses all instances running with the specified instance type. This helps you categorize the data by the type of the running instance. There are other filters available as well but these suffice as examples for individual instances and groups.
Users need their own access keys to make programmatic calls to AWS from the AWS Command Line Interface (AWS CLI), Tools for Windows PowerShell, theAWS SDKs, or direct HTTP calls using the APIs for individual AWS services. To fill this need, you can create, modify, view, or rotate access keys (access key IDs and secret access keys) for IAM users.
IAM users can be added.
If we look at the bills generated by AWS, they typically have a cost breakout like this:
IAM users can be added.
If we look at the bills generated by AWS, they typically have a cost breakout like this:
AWS Service Charges:
Elastic Compute Cloud:
US West (Oregon) Region
Amazon Elastic Compute Cloud Running Linux/UNIX
$0.00 per Linux t2.micro instance-hour (or partial hour) 261 Hrs $0.00
Total: $0.00
EBS
$0.00 per GB-month of General Purpose (SSD) 2.785 GB-Mo $0.00
Total: $0.00
Region Total: $0.00
CT to be collected: $0.00
GST to be collected: $0.00
US Sales Tax to be collected: $0.00
VAT to be collected: $0.00
Note that this bill is specific to User to region and categorized by compute or storage. It can show further drill down as reports based on instances and instance groups.
With SNS notifications we can populate a table for staging usage data that can have the following attributes
- Customer
- Region
- Service (ECS/EBS for now)
- dimension
- Instance (optional and if applicable)
- Volume (optional and if applicable)
- Current ( value )
- Cumulative (value)
- min ( applicable only for current in the absence of historical data)
- max ( applicable only for current in the absence of historical data)
- avg ( applicable only for current in the absence of historical data)
- units
- timestamp/sequence-counter ( optional for historical data)
- Created by
- Created Date
Notice that this staging table has a few salient points
- It gathers usage data but can also be simplified to allocation data. For example we need not collect the metrics provided by the AWS CloudWatch but only use the vcpus allocated for each instance. This way we can directly calculate the bill based on vcpus allocated and timeslices.
- It attempts to be as granular as possible for its metric as available from the source usage data so that services can aggregate and group by as appropriate even though there might be similar features from AWS itself. For example, we may have a way to get data based on instance groups but the records only show per instance with instance details stored in a separate table. Otherwise if the instance details are not available, then use a generic dimension for storing relevant grouping factors.
- Historical data need not be preserved as long as current and cumulative are available. This way we simplify the table even more. If contiguous timeslices data are available we can populate them as historical data so the attributes min, max and avg are not necessary.
This staging data is filled by a service reading the AWS SNS as a web server or any consumer that subscribes to those messages.
The populated data can then be used to display the bills for each customer when they login.
Sample subscription setup:
<?php
require 'vendor/autoload.php';
use Aws\CloudWatch\CloudWatchClient;
$key = "your_key";
$secret = "your_secret";
$region = "us-west-2";
$version = "latest";
$interval = 15;
// Use the us-west-2 region and latest version of each client.
$sharedConfig = [
'region' => $region,
'version' => $version,
'credentials' => array(
'key' => $key,
'secret' => $secret,
),
'key' => $key,
'secret' => $secret,
];
// Create an SDK class used to share configuration across clients.
$sdk = new Aws\Sdk($sharedConfig);
$client = $sdk->createSns();
$result = $client->subscribe(array(
// TopicArn is required
'TopicArn' => 'arn:aws:sns:us-west-2:792498758900:BillingMetrics',
// Protocol is required
'Protocol' => 'email',
));
echo 'RESULT='.serialize($result);
$result = $client->confirmSubscription(array(
// TopicArn is required
'TopicArn' => 'arn:aws:sns:us-west-2:792498758900:BillingMetrics',
// Token is required
'Token' => '2336412f37fb687f5d51e6e241d7700bdc2fd53a7a19f21d5f50d0cbe0f8a467d10f83122e7eadb59d60bcfd8434754522c8c944e52b3592cd2a0b7f5cdaab36e1c7aad614f57e70ad78fa2e4ece8bb6a9b7b13fec0464a35d59864ae1ccee29fc873310f17eeb77ff5859a22c9f411496f7b60faeea6a8f56fea96038f5f7f9',
//https://sns.us-west-2.amazonaws.com/confirmation.html?TopicArn=arn:aws:sns:us-west-2:792498758900:BillingMetrics&Token=2336412f37fb687f5d51e6e241d7700bdc2fd53a7a19f21d5f50d0cbe0f8a467d10f83122e7eadb59d60bcfd8434754522c8c944e52b3592cd2a0b7f5cdaab36e1c7aad614f57e70ad78fa2e4ece8bb6a9b7b13fec0464a35d59864ae1ccee29fc873310f17eeb77ff5859a22c9f411496f7b60faeea6a8f56fea96038f5f7f9&Endpoint=rravishankar@gmail.com
'AuthenticateOnUnsubscribe' => 'true',
));
echo 'RESULT_CONFIRMATION='.serialize($result);
?>
No comments:
Post a Comment