Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Why is Cloudtrail logging a random sourceIPAddress for freetier.amazonaws.com events?

-1

Is there a reason why Cloudtrail events for GetAccountPlanState in the Freetier service have started to show a random IP address for the sourceIPAddress value? For example, this is an excerpt from a Cloudtrail event for my user identity after running aws freetier get-account-plan-state today using the AWS CLI:

    "eventSource": "freetier.amazonaws.com",
    "eventName": "GetAccountPlanState",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "130.176.152.101",             <--------- Cloudfront IP address from France?
    "userAgent": "aws-cli <version string redacted>",
    "errorCode": "ResourceNotFoundException",
    "errorMessage": "Missing data for account: <account id redacted>",

This seems to have started on 2025-07-07 and I'm not able to find any API calls for GetAccountPlanState prior to this date. I've noticed this in several different AWS Account Cloudtrail logs, and these events seem to get logged sometimes when opening a service's Dashboard in the web console. It's likely if you check your own account's Cloudtrail logs in us-east-1 for EventName == GetAccountPlanState, you may see the same thing?

The issue here is it is difficult to tell this access apart from unauthorized access, since just looking at the sourceIPAddress, there is nothing that indicates the request is coming from an AWS service. Starting on 2025-07-30, the IP address being logged seems to have changes and is no longer coming from the US, and instead looks like it's in France. Since the IP address is a French IP, it is showing in some alerting tools as coming from another country than where I'm located which raises false alerts in some monitoring tools for User Identities.

Other AWS Services will use an amazonaws.com domain name in the sourceIPAddress field in the Cloudtrail Event for events made on behalf of a user identity, which makes it easier to filter out and to not raise false alarms. For example, when Lambda calls KMS to decrypt a function code, the Cloudtrail Event looks like this:

    "eventSource": "kms.amazonaws.com",
    "eventName": "Decrypt",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "lambda.amazonaws.com",
    "userAgent": "lambda.amazonaws.com",

Is there a reason why Freetier service is not doing this when calling get-account-plan-state? Based on this blog post, I guess this is a new feature, so maybe this is a bug? Has this started happening for other people, and is there anything we should do to our account so these events are properly logged? Are there any ways to properly identify these events as not being suspicious, other than just ignoring events for GetAccountPlanState?

Thanks for any insights anyone can provide

EDIT - 2025-08-04: I have performed some more tests and have confirmed that this behavior also happens when running write actions, such as aws --region us-west-2 freetier upgrade-account-plan --account-plan-type PAID, the sourceIPAddress value in the Cloudtrail event shows a random IP address, not from the IP address where the request originated from.

Topics
Management & GovernanceAWS Free TierAWS Well-Architected Framework
Tags
Management & GovernanceAWS Free TierAWS CloudTrailSecurity
Language
English
asked 10 months ago288 views
2 Answers
4

I believe two things you can follow now:

  1. Filter by Event Name If you're seeing false alerts, consider filtering or suppressing alerts for:
"eventSource": "freetier.amazonaws.com",
"eventName": "GetAccountPlanState"
  1. Tag Events as Internal Use your SIEM or alerting tool to tag these events as internal AWS service calls, even if the IP looks external. You can base this on the userAgent or consistent structure of the event.
EXPERT
answered 10 months ago
  • SV
    10 months ago

    Thanks for the response Kidd Ip. This is the first time I've ever seen events logged like this which is why I raised the question, it seemed very odd. Considering there are not any other AWS Services or API calls which exhibit this behavior where random IPs are logged for the sourceIPAddress in Cloudtrail events, I'm not sure if something is wrong with the account settings that is causing this, and I can not tell why this would have started to happen all of a sudden. Of course these Freetier read only events are not very critical, but if other events (such as s3:DeleteBucket) were to show the same behavior, we would not be able to ignore these events in our SIEM. This behavior would diminish the usefulness of Cloudtrail if the data in the events can not be trusted, and would need to be ignored.

0

Hey,

Hope you're keeping well.

The GetAccountPlanState calls you’re seeing are triggered automatically by the AWS Console or CLI when checking Free Tier usage, and they’re served via AWS edge infrastructure. In some cases, CloudTrail logs the public IP of the CloudFront edge location handling the request rather than an internal AWS service hostname, which is why you’re seeing IPs from different geographies. This isn’t an indication of unauthorized access, but it can cause false positives in geo-based alerts. If you need to filter these, you can match on eventSource=freetier.amazonaws.com and eventName=GetAccountPlanState in CloudTrail or your SIEM to exclude them from alerts.

Thanks and regards,
Taz

answered 6 months ago
  • SV
    6 months ago

    Hi Taz, thanks for your answer. Are you aware of any other services where this behavior happens? As far as I can tell, Free Tier events are the only ones which show random IPs in the sourceIP field. Since these alerts have started to appear, I have already set rules to ignore them in SIEM, but this behavior seems unique to the Free Tier service. I asked this question to see if there is any reason why this service behaves differently in the Cloudtrail logs, and to point out that this unique behavior for the Free Tier service creates unnecessary noise, and if other services did the same, it would be a bigger problem.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content