Build Creation Fails with "cannot assume the role, access denied" Error
If your build creation is failing with the error "cannot assume the role, access denied", this indicates that the IAM role specified in your Terraform configuration doesn't have the proper trust relationship to allow GameLift to assume it. Root Cause This error occurs when the IAM role used by your resource lacks the necessary trust relationship with the service. This can happen due to: The role was never configured with trust permissions Platform policy rotations that regenerated trust policies without including GameLift Manual modifications to roles that were later reverted by automation Solution Step 1: Verify the Current Role Configuration First, identify which role is being used in your Terraform configuration: Check your Terraform code for the resource Note the role_arn value in the storage_location block Go to AWS IAM → Roles and find this role Click on the "Trust relationships" tab Step 2: Add Trust Relationship The trust relationship should include it as a trusted service. Add or update the trust policy to include: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "gamelift.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } Step 3: Ensure Proper Permissions The role also needs permissions to access your S3 build bucket. Add this permission policy: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetObjectVersion" ], "Resource": "arn:aws:s3:::YOUR-BUILD-BUCKET/*" } ] } Step 4: Verify Terraform Configuration Ensure your Terraform configuration is using the correct role ARN: resource "awscc_gamelift_build" "this" { name = var.build_name version = var.build_version storage_location = { bucket = var.bucket key = var.key role_arn = aws_iam_role.gamelift_build_role.arn } } Best Practices Create a dedicated IAM role specifically for builds rather than reusing general-purpose roles If using infrastructure management platforms, ensure permissions are preserved during policy rotations Document any manual IAM changes to prevent them from being inadvertently reverted After making these changes, you should be able to redeploy your build successfully.
Last updated
Was this helpful?

