Lightsail container assuming IAM role from unknown AWS account

Question

I’m running Lightsail containers in account 430118835981, in region eu-west-2.

I’ve now fully rebuilt everything from scratch:

Created a new container service from the AWS Console

Built and pushed a fresh Docker image using the AWS CLI from the same account

Verified there are no AWS_* credentials in my environment, Dockerfile, or container config

I am using only the default IAM role provided by Lightsail at runtime

Inside the running container, this is the result of:

boto3.client("sts").get_caller_identity()

{
  "Account": "396913702671",
  "Arn": "arn:aws:sts::396913702671:assumed-role/..."
}

I do not own or control account 396913702671. I have never logged into it.
None of my IAM roles or policies reference it.
This is now affecting all container services, even newly created ones.

This appears to be a serious IAM misbinding or platform-level bug.
Please escalate this internally or advise how to fix it — I am on the Basic support plan and cannot open a technical case.

Thank you.

BrianDAnderson_AWS · Accepted Answer

Hello @hbuhrmann, thank you for posting this question.   Before digging into the issue, if we are not able to resolve this here in re:Post, I recommend temporarily upgrading to Developer support ($29/month) to be able to open an AWS Support Case to get assistance from a Cloud Support Engineer, then you can always downgrade back to Basic support once the issue is resolved.

Okay, so let's unpack this issue: This is not an uncommon challenge, we've seen similar behavior in the past when it comes to Lightsail and AWS-managed IAM roles.   Here's what's happening: While the container service is created and managed in your account (430118835981), the actual container runtime environment operates within an **AWS-managed** infrastructure account (396913702671). This is part of Lightsail's underlying architecture.  With that being said, let's dig into the issue:

Behavior observed:

Your container service exists in your account (430118835981)
    When containers actually run, they execute in AWS's managed infrastructure account (396913702671)
    The IAM role you see is a managed role that AWS creates to run your containers securely

This is not a bug or security issue, but rather:

An intentional design choice by AWS for Lightsail container infrastructure
    Similar to how some other AWS managed services operate "behind the scenes"
    Doesn't affect your container's ability to access resources in your account, as proper IAM role assumption chains are maintained

If you need to:

Access resources in your account: Use the default Lightsail container role normally
    Verify container identity: Look at container environment variables or service metadata rather than STS calls
    Implement IAM policies: Write them for your account (430118835981), not the infrastructure account

This architecture is generally transparent to normal container operations, only becoming visible when making direct AWS API calls.

**Troubleshooting Tips**:

Verification Steps to Take:

# Inside your container, run these commands to gather more information
aws sts get-caller-identity
aws sts get-session-token
env | grep AWS
curl -s http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

Recommended Actions:

a. First, verify the container service's role:
aws lightsail get-container-services --region eu-west-2

b. Check if there are any AWS Organizations relationships:
aws organizations list-accounts

Important Context: The account 396913702671 appears to be an AWS-owned account, which suggests this could be related to the AWS Lightsail service infrastructure. This pattern sometimes emerges when there's an issue with the service-linked role configuration or during regional infrastructure updates.

Next Steps:

a. As a temporary workaround, you can:

Create a custom IAM role for your container service
    Explicitly set AWS credentials using environment variables
    Use AWS SDK configuration files with explicit role assumption

Security Implications: While this appears to be a platform-level issue, monitor your CloudTrail logs for any unexpected API calls from this role/account combination.

Alternative Workarounds:

a. Use explicit IAM credentials:
# In your container configuration, add environment variables:
AWS_ACCESS_KEY_ID=your_access_key
AWS_SECRET_ACCESS_KEY=your_secret_key
AWS_SESSION_TOKEN=your_session_token

b. Create a custom IAM role:
# Create a new IAM role with required permissions
# Add trust relationship to Lightsail service
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lightsail.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Consider Alternative Services: If the issue persists, consider migrating to:

Amazon ECS on EC2 (more control over IAM)
    Amazon ECS on Fargate
    Amazon EKS
    Regular EC2 instances with Docker

Temporary Solution: If you need immediate functionality, you could:

Use the AWS SDK with explicit credential configuration
    Implement your own credential provider that explicitly assumes the correct role
    Use the AWS CLI with --profile to ensure correct credential usage

Example SDK configuration:
import boto3

session = boto3.Session(
    aws_access_key_id='YOUR_ACCESS_KEY',
    aws_secret_access_key='YOUR_SECRET_KEY',
    region_name='eu-west-2'
)

# Use this session for AWS API calls
client = session.client('service-name')

Hopefully this helps shed some light on the issue.  Once again, if you get stuck, consider going the route of upgrading to Developer support in order to be able to open an AWS Support Case.

Thank you for using AWS!
Brian

Lightsail container assuming IAM role from unknown AWS account

Inside your container, run these commands to gather more information

In your container configuration, add environment variables:

Create a new IAM role with required permissions

Add trust relationship to Lightsail service

Use this session for AWS API calls

Relevant content