TSE-SE Sample Architecture SCP AWSAccelerator-Quarantine-New-Object update to solve timeout issue about landing-zone-accelerator-on-aws HOT 5 CLOSED

This is a default quota from AWS for new accounts. Try to reach AWS Support and they will help you. https://repost.aws/questions/QUNe84jgBRQ9G5ACLDUzCt4w/free-tier-accounts-code-build-stops-after-45-min

from landing-zone-accelerator-on-aws.

Which stage or stages are timing out?

from landing-zone-accelerator-on-aws.

hello @crissupb thanks for the question.

we are trying to deploy the tse-se architecture and our CodeBuild job “AWSAccelerator-ToolkitProject:'ID'” had failed at Stage "Deploy" step "network-associations" due to the build timeout which had happened at 45 minutes.

we set the project timeout value to 8 hours however when we start a build, the project level build timeout setting of 8 hour was not being applied to the individual builds, instead it was defaulting to 45 minutes.

We are trying to deploy a Shared Network Configuration with 3 Accounts, One Account is our Shared Services Account, which deploy a MAD and shared the directory with the other 2 Accounts.

This takes more than 45 min but because of the build Timeout the pipeline fails and rollback the cloudformation stack.

from landing-zone-accelerator-on-aws.

Hello @MigueAngelRamirez please let us know if you are still experiencing problems with CodeBuild timeouts. @rboboc111 Thank you for the possible solution!

In the meantime, our team will evaluate the feature request to increase the default CodeBuild timeout.

from landing-zone-accelerator-on-aws.

hey @hickeydh-aws,
we try to deploy the LZA TSE-SE sample architecture but this solution was failing on the Network_Associations_Config step of the Deploy stage.

We found out that the Managed Active Directory instance did not receive the resource signals in time, which cause the CodeBuild Timeout.

The instance profile tried to make a GetSecretValue call. However, it was being denied by a service control policy AWSAccelerator-Quarantine-New-Object.

We solved this by adding the EC2-Default-SSM-AD-Role to the policy document to successfully deploy the architecture.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyAllAWSServicesExceptBreakglassRoles", "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "ArnNotLike": { "aws:PrincipalARN": [ "arn:${PARTITION}:iam::*:role/${MANAGEMENT_ACCOUNT_ACCESS_ROLE}", "arn:${PARTITION}:iam::*:role/aws*", "arn:${PARTITION}:iam::*:role/AWSA*", "arn:${PARTITION}:iam::*:role/cdk-accel-*", "arn:${PARTITION}:iam::*:role/EC2-Default-SSM-AD-Role" ] } } } ] }

Thanks

from landing-zone-accelerator-on-aws.