[ECS Fargate] [Bug]: Set Environment variables at Machine level in Windows Container when ECS Task Spins up

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about the Issue**
We have a Windows Service application which currently runs on the on-prem environments, we are in the process of migrating the on-prem environments to the AWS Cloud and using the AWS ECS Fargate services and availing a few of the services in the existing Application.

We have modified our application to write the log into the Cloud Watch using the AWS SDK rather than writing to the local file (current approach) when we deployed the container we got the below error.

**Unable to get IAM security credentials from EC2 Instance Metadata Service.**

In order to find the root cause of this issue, we have written a POC application and run it is a console application. When we deployed this we did not get any error. So we have updated the same logic to the POC windows service application and still got the same error. So we end up printing all the environment variables in both applications to make sure we are getting all the values correctly.

Find the Screenshot below for reference


As per the image, we could see the environment variables we set as part of the Task Definition (LOG_GROUP_NAME & LOG_STREAM_NAME) along with the AWS Environment variables are not populating in the Windows Service Application.

Based on this We believe that when ECS spins up a Task all the environment variables are set only at the default **user level**, **not the machine level** which kind of breaks our code as we have a windows service which will run as a LocalSystem account and does not have access to the user level Environment variable

**Are you currently working around this issue?**
For the time being, we have developed a sample C# program which executes the PowerShell script Get-ChildItem Env: -Include 'AWS*', 'ECS*' -Recurse and set these to Machine level environment variables to make it work during the Start-Up

**Environment Details**

- Launch Type - Fargate (For our actual solution, for POC purposes we even tried this in the ECS EC2 and had the same issue)
- Role - We have provided admin access for both Task and Execution Role
- Operating System Family - Windows Server 2019 Full
- Platform Version - LATEST (1.0.0)
- Memory 8GB, CPU - 4
- Container Base Image - mcr.microsoft.com/windows/servercore:ltsc2019-amd64
- .Net Framework 4.8 which we have installed on top of the Container Base Image

**AWS Case ID**
We even discussed the same issue with the AWS Team and the details can be found in Case ID: 10253345431

**Attachments**

- Docker File referenced from https://github.com/microsoft/dotnet-framework-docker/blob/a853e05e409b3009b059fa3945837765c9bc43b8/src/runtime/4.8/windowsservercore-ltsc2022/Dockerfile

No repository file or test is identified; start by reviewing the referenced Windows container Dockerfile and the ECS task startup behavior described in the report. Reproduce the Windows service case with the supplied PowerShell environment-variable check, and consider the issue resolved when task and AWS variables are available at machine level to the LocalSystem service without the workaround.

Written by the indexing model from the issue text.