0

As a sysadmin I typically monitor at the server level, OS level, and application level. I can even do data-center monitoring (temperature of the building, power load, etc.).

My organization is planning on moving some production services to AWS. AWS provides notifications about how much you are spending, but since I don't pay the bills I don't really care about that. What I do care about are events that can affect the services I manage. So I want to add billing level monitoring. In the same way I am alerted when a physical server has a problem I want to be alerted when

  1. The credit card associated with the accounts has a problem (expires, limit exceeded, etc.) or is close to having a problem

  2. The account is overdue on a payment

  3. When an AWS asset (EC2 instance, Route 53 record, etc.) is close to, or has become, inaccessible, or when it is going to be deleted due to billing-related issues.

Are these sorts of alerts possible?

1 Answer 1

1

Items 1 and 2: AWS sends such emails to the email address associated with the root account, so choose that address carefully, and ensure that it is monitored.

There does not appear to be another notification mechanism. These two items are essentially the same as far as I can tell -- if the payment method is declined, the account is technically overdue, since payment is due immediately.

There are other good reasons to monitor this email account, too -- AWS has been known to go above and beyond their portion of the shared security model on occasion... for example, they performed a proactive audit and notified affected customers that they should verify whether they really did intend to bypass the secure default settings on S3 buckets and make them publicly accessible. (As you may have noticed from recent news items, some combination of lack of controls, carelessness, inexperience, or laziness sometimes prompts people to configure buckets for open access.)

You can get also the monthly invoice emailed as a PDF and use this as a trigger to cross-verify that payment was successful.

Item 3 is a side effect of failing to react to the other two. An account that remains unpaid is subject to termination, presumably without further notice. The exact terms of when the services might be disrupted is not something for which I can find a citation.

Anecdotally, AWS appears to suspend access, somewhat piecemeal, nondestructively at first.

I've seen customers not pay due to an expired card, and the first side effect after some time elapses is S3 buckets returning an apparently undocumented error response:

<Error>
  <Code>AllAccessDisabled</Code>
  <Message>All access to this object has been disabled</Message>
  <RequestId>...</RequestId>
  <HostId>...</HostId>
</Error>

This appears to be the result of some kind of kill-bit that can be set for an entire bucket. The customer fixed the billing issue, service was restored, and no content was lost.

Additionally, I have one relatively large account whose bank repeatedly denied the recurring monthly AWS charge (~$5,000 iirc) as suspicious desipite the customer's request that the bank accept them as genuine. This never resulted in any service disruptions on the account.

3
  • My organisation has an AWS account manager, who would contact us if something unusual happened. We also pay by invoice, rather than credit card. This may only be possibly only for large customers, but it might be worth looking into more of a human relationship with Amazon to mitigate some of these risks.
    – Tim
    Sep 4, 2017 at 18:50
  • Good point, @Tim. We have one, too, but I've never actually known what triggered the establishment of relationship, so I didn't mention it. Any idea how to pursue that with AWS? Sep 4, 2017 at 18:56
  • I called them, but we're part of a very large organisation that has an umbrella contract so they were happy to talk. I'd try calling them and asking if an account manager can be assigned.
    – Tim
    Sep 4, 2017 at 19:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .