sourceIPAddress: Internal là như nào?
Recently when I look at CloudTrail logs, I find that there are some logs which have “sourceIPAddress”: “AWS Internal”, and some others is “sourceIPAddress”: “<IP address>”, even though all of those actions were conducted in the AWS management console.
I have read the docs:
and understand that there are 2 condition that sourceIPAddress become Internal:
- if the request was made with a proxy client (such as the AWS Management Console)
- and sessionCredentialFromConsole is present with a value of true.
If the request was made with a proxy client, the tlsDetails is not shown.
My question is:
- Is there any services list that if you make request in those service console, the sourceIPAddress will be Internal?
- Why when I describle, for eg, Redshift cluster in the Management Console, the sourceIPAddress is internal but when I list bucket in AWS console, the request show IP and tlsDeail? (i.e. In which case the request will be made with a proxy client, in what case not? – assumed that all request made using AWS Management Console)
Warm greetings from AWS!
Thank you for getting in touch with us at AWS Premium Support. I am Amit, and I will be assisting you on this case today.
From the case notes, I understand you have some queries about “sourceIPAddress”: “AWS Internal” field, present in few of your CloudTrail logs. Please allow me to answer them one by one.
As you have correctly pointed out that when the value of sourceIPAddress is replaced by AWS Internal and the value of userAgent is replaced by AWS Internal, usually the calls are made with a proxy client (such as the AWS Management Console), and sessionCredentialFromConsole is present with a value of true.
A “service list” that categorises the services for which the “sourceIPAddress” would be “AWS Internal” does not exist. Please note that each service has a unique architecture, and behaves accordingly – some services are dependent on other services in the backend, and therefore, “AWS Internal” is recorded in SourceIPAddress and userAgent when the AWS services are making requests on your behalf to other AWS resources.
For example: Suppose an IAM user ‘arn:aws:iam::xxxx:user/abc’ has logged into the AWS Management Console and is trying to open EC2 service console. As EC2 console has a list of LoadBalancers, Volumes, Instances and Key pairs etc., so in order to display these details, EC2 service in the backend makes these describe API calls on behalf of the user and hence, for these calls, the SourceIPAddress and userAgent will be marked as ‘AWS Internal’.
You could also refer to:
Regarding your second query, that when you call “ListBuckets” you get an IP address in your CloudTrail logs, whereas when “DescribeClusters” API call is made, the “sourceIPAddress” is ”AWS Internal”.
Please note there is an exception here: when you make “ListBuckets” API call – to get a list of all buckets owned by the authenticated sender of the request, the response for this call involves HTTP or HTTPS (hence the “tlsDetails” is present in logs). Since it is an HTTP based request-response, the browser is involved in making the request, and therefore, the IP of the browser is captured.
For “DescribeClusters” API call, response is not HTTP based; as a result the request is passed from AWS Management Console(proxy) and the “sourceIPAddress” is ”AWS Internal”.
As stated above, each service has a unique design; therefore, it is not possible to know which API calls will use TLS without checking the individual documentation for the respective API.
- If an AWS service is dependent on another AWS service, the calls made by first service to second service – in order to function properly, will be marked internal.
- Even if you call certain API from AWS Management Console, if their response involves HTTP or HTTPS, the IP address of the browser will be recorded in the logs. For all other API calls, where “tlsDetails” field is not present, “sourceIPAddress” is ”AWS Internal”.
I trust you will find this information helpful. If you have any questions or concerns, please feel free to reach out to me. I will be more than happy to assist.
Have a great day and stay safe!
References:  ListBuckets —
 DescribeClusters —
We value your feedback. Please share your experience by rating this correspondence using the AWS Support Center link at the end of this correspondence. Each correspondence can also be rated by selecting the stars in top right corner of each correspondence within the AWS Support Center.
Best regards, Amit M. Amazon Web Services