- Newest
- Most votes
- Most comments
Not here to offer a solution unfortunately, but just some comments.
Your figures are based on the month ending at exactly midnight UTC on the first day of the month, which is also when AWS says the billing cycle starts and ends https://repost.aws/knowledge-center/monthly-aws-billing But it seems the total number of hours that AWS is charging you for will align with your figures only if the billing period starts and ends at 01:00 UTC on the first day of the month.
UTC+1 is the timezone for all of the eu-central, eu-south & eu-north regions, as well as eu-west-3 (Paris), albeit just now during the northern hemisphere summer they're on UTC+2.
eu-west-1 & 2 (Dublin & London) timezone is GMT, which is to all intents and purposes the same as UTC. But just now in the summer they're on UTC+1.
Is your instance in any of these regions? Whilst it wouldn't be consistent with what's in the knowledge doc above, it may be a plausible explanation for why things are out by an hour.
And/or the tool that you are using to parse the CloudTrail logs, is it reading the raw data in UTC and then "localising" the time when it formats the output? If your location, or the region of the AWS service that's parsing the logs, is one hour ahead of UTC that could explain why things have slipped by an hour.
It doesn't look like you are out of pocket, the cumulative number of hours of EC2 running time is correct. The worst that can happen is you are over-billed by 0.2% in June, and under-billed by the same in July.
It may be an interesting exercise to spin up a temporary EC2 in ap-southeast-2 (UTC+10) for a few hours at the end of this month & start of next, and then see what quantities you get billed for in each period. This would clearly show whether the billing period starts and ends at midnight UTC or midnight in the region where the instance is running.
I think what you are looking for is the AWS Cost and Usage Reports (CUR). Full documentation on CUR is available at the following link.
https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html
What are AWS Cost and Usage Reports?
The AWS Cost and Usage Reports (AWS CUR) contains the most comprehensive set of cost and usage data available. You can use Cost and Usage Reports to publish your AWS billing reports to an Amazon Simple Storage Service (Amazon S3) bucket that you own. You can receive reports that break down your costs by the hour, day, or month, by product or product resource, or by tags that you define yourself. AWS updates the report in your bucket once a day in comma-separated value (CSV) format. You can view the reports using spreadsheet software such as Microsoft Excel or Apache OpenOffice Calc, or access them from an application using the Amazon S3 API.
AWS Cost and Usage Reports tracks your AWS usage and provides estimated charges associated with your account. Each report contains line items for each unique combination of AWS products, usage type, and operation that you use in your AWS account. You can customize the AWS Cost and Usage Reports to aggregate the information either by the hour, day, or month.
AWS Cost and Usage Reports can do the following:
- Deliver report files to your Amazon S3 bucket
- Update the report up to three times a day
- Create, retrieve, and delete your reports using the AWS CUR API Reference
In particular https://docs.aws.amazon.com/cur/latest/userguide/billing-columns.html#b-B
bill/BillingPeriodEndDate The end date of the billing period that is covered by this report, in UTC. The format is YYYY-MM-DDTHH:mm:ssZ.
bill/BillingPeriodStartDate The start date of the billing period that is covered by this report, in UTC. The format is YYYY-MM-DDTHH:mm:ssZ.
Relevant content
- asked 5 months ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated a year ago
Hi Steve,
My machine is indeed in Ireland, which in Summer is UTC+1, as you pointed out. I now realize that if the first and last day of the month are taken +1 hour, the numbers add up correctly. Having the event times in UTC+0 confused me.
I appreciate that you didn't answer me with a "check the docs" type of answer, but instead thought through my problem to understand what could be going on. Thank you very much Steve!
No worries Gabriel, looked at as a maths puzzle it was fun to work through :-)