DEV Community: Jana Hockenberger

Automatically Upload Lambda Layer Packages to S3

Jana Hockenberger — Thu, 12 Jun 2025 10:26:46 +0000

Why using Lambda Layers?

The benefits of AWS Lambda Layers should not be missed. With Lambda Layers you get the possibility to package code which can then be reused in different functions.

In big environments usually all Lambda Layers are located in one specific account and then shared via Layer Version Permissions to then get used by the necessary functions.

You can use Lambda layers either to write your own functions or to make entire packages available which are not covered by the Lambda runtimes. This blog article will provide you a solution on how you can upload Lambda layer packages with complex folder structures to a S3 Bucket. As you should always deploy your resources with Infrastructure as Code, a manual upload is not a satisfying solution here.

Deep-Dive into the Lambda Function

All steps are covered in one Lambda function. Depending on your favor, you can also split them up. In this example I will guide you through all steps being executed in one function.

Summary of the procedure

The base procedure is as follows:
The package is placed in our Customizations for Control Tower (CfCT) repository. A Lambda functions checks the path where the package is located, and recursively loop through all folder, sub folders and files.
The solution leverages the non-persistent storage provided by default in every Lambda function. The same folder and file structure then gets created in the local /tmp directory.
After that the local directory gets zipped and uploaded to S3 where another automatism gets the Zip File to then add it to the Lambda layers.

This blog article should only focus on the upload part to S3. This part is quite tricky, because the folder structure is not clear and the automatism should stay dynamic enough to also be used for further packages which should get added as a layer with different folder structures.

Necessary environment variables

This example uses Bitbucket as a repository hosting service. Prerequisites are a working CodeStar Connection between the CfCT pipeline including authentication to have the necessary access to the repository.

BITBUCKET_WORKSPACE_NAME = os.environ['WORKSPACE_NAME']
BITBUCKET_REPO_NAME = os.environ['REPOSITORY_NAME']
BITBUCKET_TOKEN_PARAMETER = os.environ['BITBUCKET_TOKEN_PARAMETER']
BITBUCKET_BRANCH_NAME = os.environ['BRANCH_NAME']
BUCKET_NAME = os.environ['BUCKET_NAME']

Corresponding environment variables should be set in the Lambda function which have all necessary Bitbucket information included like the Bitbucket workspace, the repository name, the token parameter and the branch name.

Another environment parameter is a list of the folder paths, where the packages are located. Also the S3 bucket where the Zip file will get uploaded should be set as an environment variable

How to trigger the Lambda function

The Lambda function gets triggered as soon as the CodePipeline starts. You can realize this with a separate CodePipeline or an EventBridge Trigger which listens to the corresponding CloudTrail event.

First the API token is retrieved from an encrypted SSM Parameter to be able to set up the connection to the Bitbucket repository

def getApiToken():
    ssmClient = boto3.client('ssm')
    try:
        response = ssmClient.get_parameter(
            Name=BITBUCKET_TOKEN_PARAMETER,
            WithDecryption=True
        )
        token = response['Parameter']['Value']
        return token
    except ClientError as e:
        print(e)
        raise e

Collecting all items from the repository

The Lambda functions loops through every entry of the folder path variable and calls the getFolder method

In the getFolder method the base URL for Bitbucket is joined and the token is set in the headers variable. This step is necessary to access the remote repository.

def getFolder(token, folderPath, s3Client):
    print(f"Checking Folder Path {folderPath}")
    baseUrl = f'https://api.bitbucket.org/2.0/repositories/{BITBUCKET_WORKSPACE_NAME}/{BITBUCKET_REPO_NAME}/src/{BITBUCKET_BRANCH_NAME}/{folderPath}'
    print(f"Base Url: {baseUrl}")
    headers = {'Authorization': f'Bearer {token}'}

After that the getAllItems method gets called. An empty list variable gets initialized and with the help of the request package a get method gets called to capture all the files from the provided folder path out of the repository

def getAllItems(url, headers):
    files = []
    while url:
        response = requests.get(url, headers=headers)
        response.raise_for_status()  
        data = response.json()
        files.extend(data.get('values', []))

        url = data.get('next', None)
    return files

Back to the getFolder method, the localFolderPath gets set to /tmp because this is where the package structure should be temporarily saved. With the help of the os package and the makedirs package a folder with the same name gets created in the Lambda functions environment.

localFolderPath = os.path.join('/tmp', folderPath.lstrip('/'))
    os.makedirs(localFolderPath, exist_ok=True)
    print(f"Created local folder: {localFolderPath}")
    newFolderPath=""

Local creation of the package structure

Now comes the complicated part: The function iterates through all items retrieved from the getAllItems method using a for-loop. The item object looks like this:

{
  "path": "lambda/layers/xxxxx",
  "commit": {
    "hash": "xxxxx",
    "links": {
      "self": {
        "href": "https://api.bitbucket.org/2.0/repositories/xxxxx/commit/xxxxx"
      },
      "html": {
        "href": "https://bitbucket.org/xxxxx/commits/xxxxx"
      }
    },
    "type": "commit"
  },
  "type": "commit_file",
  "attributes": [],
  "escaped_path": "lambda/layers/xxxx",
  "size": 1779,
  "mimetype": "text/x-python",
  "links": {
    "self": {
      "href": "https://api.bitbucket.org/2.0/repositories/xxxxx"
    },
    "meta": {
      "href": "https://api.bitbucket.org/2.0/repositories/xxxxx"
    },
    "history": {
      "href": "https://api.bitbucket.org/2.0/repositories/xxxxx"
    }
  }
}

The item path and the item type of the current file gets saved into two variables

If the item_type equals commit directory, the old path plus the name of the item gets set as the new_folder_path and the folder gets created in the /tmp directory as well. After that, the getFolder function gets called again with the new folder path.

for item in repoItems:
        itemPath = item['path']
        itemType = item['type']

        # Check whether itemType is a directory
        if itemType == 'commit_directory':
            itemPath = itemPath.split('/')[-1]
            newFolderPath = os.path.join(folderPath, itemPath).lstrip('/')

            # Folder gets created locally
            localSubfolderPath = os.path.join('/tmp', newFolderPath)
            os.makedirs(localSubfolderPath, exist_ok=True)
            print(f"Found folder and created local subfolder: {localSubfolderPath}")

            # getFolder function gets called again with new folder path
            getFolder(token, newFolderPath, s3Client)

If the itemType equals commit_file, the file name gets read out of the whole path. Then the url variable gets set to point to the file in the Bitbucket directory and is created in the /tmp directory under the correct sub folder.

elif itemType == 'commit_file':
            print(f"Found file: {itemPath}")
            fullPath = item['path']
            pathParts = fullPath.split('/')
            fileName = pathParts[-1]

            # Get the file content from Bitbucket and upload it to S3
            url = f'https://api.bitbucket.org/2.0/repositories/{BITBUCKET_WORKSPACE_NAME}/{BITBUCKET_REPO_NAME}/src/{BITBUCKET_BRANCH_NAME}/{folderPath}/{fileName}'
            headers = {'Authorization': f'Bearer {token}'}
            response = requests.get(url, headers=headers)
            if response.status_code == 200:
                localFilePath = os.path.join(localFolderPath, fileName)
                with open(localFilePath, 'wb') as file:
                    file.write(response.content)
                print(f"Found file and created local file: {localFilePath}")
        else:
            print(f"Unknown item type: {itemType} for {itemPath}")
    return newFolderPath

Zip and upload of the package to S3

After the for loop is finished, the processFolder function gets called to read out the package name of the Lambda package
The addFolderToArchive function gets called next.

def getAllItems(url, headers):
    files = []
    while url:
        response = requests.get(url, headers=headers)
        response.raise_for_status()  
        data = response.json()
        files.extend(data.get('values', []))

        url = data.get('next', None)
    return files

This method is responsible for uploading the package structure to S3. First the current timestamp is generated, then the name of the Zip file is set. With the shutil package the folder gets zipped via the make_archive function and uploaded to the provided bucket from the environment variable. The last step is to save the package name with the timestamp in the end in a SSM parameter which can then further be used to build the part where the layer itself gets created and shared with the other accounts.

def addFolderArchive(folderName, folderPath, s3Client):
    timeStamp = datetime.datetime.now().strftime("%Y%m%d%H%M%S")
    zipFileName = f'{folderName}_{timeStamp}.zip'

    fullFolderPath = f'/tmp/{folderPath}/{folderName}'
    tempZipFile = f'/tmp/{zipFileName}'

    # Zip File gets created and uploaded to S3
    shutil.make_archive(tempZipFile[:-4], 'zip', fullFolderPath)
    s3Client.upload_file(tempZipFile, BUCKET_NAME, zipFileName)

    # SSM Parameter gets set with package name
    ssm_client = boto3.client('ssm')
    ssm_client.put_parameter(
        Name=f'/org/layer/package/{folderPath}/{folderName}/zipArchive',
        Description=f'Archive name for {folderName} in s3 Bucket {BUCKET_NAME}',
        Value=zipFileName,
        Type='String',
        Overwrite=True
    )

    # Local files are removed
    if os.path.exists(tempZipFile):
        os.remove(tempZipFile)
    if os.path.exists(fullFolderPath):
        shutil.rmtree(fullFolderPath)
    print(f"Folder {folderName} archived as {zipFileName} and uploaded to S3")

The local zip file gets created from the Lambda environment and the function is finished.

The whole Lambda code can be found in my GitHub account.

About Me

Hi! My name is Jana, I live in the Southwest of Germany and when I'm not smashing weights in the gym I love to architect solutions in AWS making my and the customers lives easier.

My computer science journey started as an On-Premise System Administrator over the time developing to an AWS Architect. As I know both the "old" and "new" world, I know common pain points in architectures and being able to provide solutions to solve them and making them not even more efficient but also cheaper!

I enjoy to learn and as the AWS portfolio is evolving all the time, I also try to stay up to date by getting certified and checking out newly launched products and services.

If you want to lift your environment either to the cloud or want to leverage your already migrated environment to use more of the cloud services, hit me up or check out Public Cloud Group GmbH!

If you want to support me, you can buy me a coffee!

About PCG

Public Cloud Group supports companies in their digital transformation through the use of public cloud solutions.

With a product portfolio designed to accompany organisations of all sizes in their cloud journey and competence that is a synonym for highly qualified staff that clients and partners like to work with, PCG is positioned as a reliable and trustworthy partner for the hyperscalers, relevant and with repeatedly validated competence and credibility.

We have the highest partnership status with the three relevant hyperscalers: Amazon Web Services (AWS), Google, and Microsoft. As experienced providers, we advise our customers independently with cloud implementation, application development, and managed

How To: Update AWS SRA in your Control Tower environment

Jana Hockenberger — Mon, 14 Apr 2025 06:46:47 +0000

This blogpost provides you with instructions on how to update the AWS SRA in your CfCT environment. With just a handful of steps you can easily update this on your own to make sure that you always have the current version installed.

What does SRA provide?

The AWS Security Reference Architecture GitHub Repository provides you a broad range of security services including granular parameterization. You can enable services like GuardDuty, define which services you want to manage or include a solution which for example notifies you when you have unencrypted EBS volumes. With all these settings in two files you save a lot of time on developing custom build StackSets which you would need to manage yourself. AWS SRA follows the Best-Practices approach and sets delegated administrator for services where it makes sense. It is under constant development supplying you with the newest services and solutions AWS launches. You can find further information about this Repo on the following link.

Unfortunately so far SRA doesn’t provide an update procedure which results in adding new services as separate StackSets outside of SRA - not a really smooth solution.

As we faced this issue in our environment too we took a deeper look at the whole SRA setup process and what we need to touch to be able to update the framework. Indeed we then were able to update our SRA with just a small amount of easy steps. Just follow the instructions below!

How to Update SRA:

The whole code for the SRA services and solution is located in a S3 Bucket named sra-staging-ACCOUNTID-REGION in the account from where you deployed this solution.

First step is to create a folder named archive and to move all folders inside this S3 Bucket to the archive folder. This is done in case anything goes wrong on the following steps, you are still able to roll back.

If you now look at the root directory of the S3 Bucket it should look like this:

Now open the CodeBuild console and click on the CodeBuild project sra-codebuild-project

This CodeBuild project calls the public SRA GitHub repository and copies all the files to the S3 Bucket. So in case it detects that the folders are not present, it will copy them again. This will enable us to get the most recent version of the SRA solutions.

To achieve this, run “Start build” for the CodeBuild project. After around 5 minutes, the run should show as successful:

As new solutions may also include new available parameters, this is the next step we need to check. When first setting up SRA you download a manifest.yaml and a sra-easy-setup.yaml.

Download these files again with the curl command provided on the SRA instruction page:

Open the files in your IDE and compare them to the current SRA files in your repo.

Do this with both, the manifest.yaml and the sra-easy-setup.yaml. Transfer the new content to your existing file, do not replace them! These files include all the parameters you set and you don’t want them to be overwritten.

After you finished this step, you can push your changes and wait for your CodePipeline to update the SRA StackSet.

In case you did everything correct, your StackSet Update should be green and you can now use the new SRA features!

About Me

Hi! My name is Jana, I live in the Southwest of Germany and when I'm not smashing weights in the gym I love to architect solutions in AWS making my and the customers lives easier.

I enjoy to learn and as the AWS portfolio is evolving all the time, I also try to stay up to date by getting certified and checking out newly launched products and services.

If you want to lift your environment either to the cloud or want to leverage your already migrated environment to use more of the cloud services, hit me up or check out Public Cloud Group GmbH!

If you want to support me, you can buy me a coffee!

About PCG

Public Cloud Group supports companies in their digital transformation through the use of public cloud solutions.

🧽 Cleaning up Security Hub with AWS Resource Explorer 🫧

Jana Hockenberger — Mon, 09 Dec 2024 14:02:55 +0000

Config and Security Hub are probably one of the most used services to get an overview over the compliance of your resources and your overall security store.

Config lets you run predefined or custom rules over your AWS resources to check whether they are compliant or not.
Security Hub uses different Security Standards including predefined Severity categories to categorize findings and providing an overall overview over your Security status. Since some time already Config Results are automatically transferred to Security Hub giving you the possibility to just check one tool for your current security status.

Config and Security Hub as Mess-Makers

As AWS environments are hardly static in its behavior, a lot of resources will be removed, created or modified making the environment being in a constant state of change. If a resource which has been scanned by Config gets deleted, it will result in Security Hub in a NOT_AVAILABLE finding. The default view in Security Hub will still show you this finding as the findings Record State is still set to active.
If AWS realizes that the state of these NOT_AVAILABLE findings didn't change for over 90 days, they will get archived automatically, quite a long time period right?

Everyone working with the Security Hub in bigger environments using several Config Rules and Security Standards will know how overwhelming it feels like opening the Security Hub console feeling like you can never bear this amount of findings. But as written above not all of these findings belong to still existent findings.

If you're orderly like me, you would rather prefer a solution which will automatically check the existence resources with the NOT_AVAILABLE state and resolve the findings belonging to resources that are already deleted.

So lets dive into an early Spring Cleaning and clean up this mess with a simple lambda function!

What is the Resource Explorer?

This solution is leveraging the Resource Explorer services and is a prerequisite to keep this automation running.

The AWS Resource Explorer is a resource search and discovery service letting you gather all resources in your organization. You can provide a broad range of inputs like the ARN, a string or a tag key. The output provides you all information which you would also get when calling the resource.

So if we would search for a resource which doesn't exist, we just don't get any output. Makes sense right?

Before deploying the Lambda function, make sure to set up Resource Explorer correctly also including all relevant regions where you have deployed resources. All information regarding the setup can be found in the AWS Documentations

All set up? Let's look at the Lambda!

Cleaning up the mess

The function starts off with a Security Hub paginator to gather all current findings. We are filtering the output by the ComplianceStatus which should be NOT_AVAILABLE, the RecordState set to ACTIVE to not get already archived ones and the WorkflowStatus not being set to RESOLVED.
Then we start looping over the findings capturing some variables out of the output like the ARN of the resource belonging to the findings.

def lambda_handler(event, context):
    securityhub = boto3.client('securityhub')
    paginator = securityhub.get_paginator('get_findings')


    finding_filters = {
        'ComplianceStatus': [
            {
                'Value': "NOT_AVAILABLE",
                'Comparison': 'EQUALS'
            }
        ],
        'RecordState': [
            {
                'Value': "ACTIVE",
                'Comparison': 'EQUALS'
            }
        ],
        'WorkflowStatus': [
            {
                'Value': "RESOLVED",
                'Comparison': 'NOT_EQUALS'
            }
        ]
    }

    page_iterator = paginator.paginate(Filters=finding_filters)
    for page in page_iterator:
        for finding in page['Findings']:
            resource = finding['Resources'][0] 
            resource_id = resource['Id']

            exists = resource_exists(resource_id)

            if exists==False:
                resolve_sechub_finding(finding)


    return {
        'statusCode': 200,
        'body': json.dumps('Security Hub Finding Compliance Status Check Completed.')
    }

Then the resource_exists method gets called using the Resource Explorer to check whether the resource is still existent. As we learned earlier, if it has been deleted, the Resource Explorer just delivers no output, which will return a False boolean in our function.

def resource_exists(resource_id):

    resexp = boto3.client('resource-explorer-2')

    try:
        print(f"Search for resource {resource_id}")
        results = resexp.search(QueryString=resource_id)
        if resource_id in results['Resources'][0]['Arn']:
            print(f"Resource {resource_id} still exists.")
            return True
        else:
            print(f"Resource {resource_id} doesn't exist anymore.")
    except Exception as e:

        return False

    return False

The next step is probably obvious. We check whether the resource check returned a False, and if so, we set the WorkflowStatus of the corresponding finding to Resolved adding a note that this state change was executed by the automation.

def resolve_sechub_finding(finding):

    sechub = boto3.client('securityhub')

    try:
        print(f"Finding {finding['Id']} will be resolve as resource not exists any more.")
        response = sechub.batch_update_findings(
                    FindingIdentifiers = [{'Id': finding['Id'], 'ProductArn': finding['ProductArn']}],
                    Workflow = {
                        'Status': 'RESOLVED'
                    },
                    Note = {
                        "Text": "This resource no longer exists. Findings for this resource have been set to RESOLVED.",
                        "UpdatedBy": "DeletedresourceFindingResolver"
                    }
                )

    except Exception as e:
        print(e)

So if you now open the default view of the Security Hub Findings we can enjoy our tidied up results leaving off just the eligible Findings.

I would suggest to also add an Eventbridge Scheduled Rule to have this function running on a regular basis. In huge environments it may also make sense to play around with the Memory to not run into a timeout.

About Me

Hi! My name is Jana, I live in the Southwest of Germany and when I'm not smashing weights in the gym I love to architect solutions in AWS making my and the customers lives easier.

I enjoy to learn and as the AWS portfolio is evolving all the time, I also try to stay up to date by getting certified and checking out newly launched products and services.

If you want to lift your environment either to the cloud or want to leverage your already migrated environment to use more of the cloud services, hit me up or check out Public Cloud Group GmbH!

If you want to support me, you can buy me a coffee!

About PCG

Public Cloud Group supports companies in their digital transformation through the use of public cloud solutions.

Automated Control Rollout in AWS Control Tower

Jana Hockenberger — Fri, 15 Nov 2024 07:35:25 +0000

The Power of Control Tower Controls

Control Tower provides a lot of helpful features when trying to assist you to manage your multi-account environment. One of these features is the usage of the so-called Controls.

Control Tower Controls help you to setup guardrails making your environment more secure and helping you ensuring governance across all OUs and accounts.

These Controls can be split up into three different groups:

Preventive Controls → With the usage of Service Control Policies this type of control prevent you doing something by setting a Deny to a specific action. An example for a Preventive Control is the Disallow Creation of Access Keys for the Root User Control
Detective Controls → This creates a Config Rule checking if the corresponding resource has a non compliant state which then can be leveraged to a remediation action. An example Control here is Detect Whether Unrestricted Incoming TCP Traffic is Allowed
Proactive Controls → The setting of IAM Permissions is used here to proactively make sure that specific actions for specific service or user can not be done. An example is Require AWS Lambda function policies to prohibit public access.

The Bad News

When using a Control Tower environment with a nested OU structure, all underlying OUs inherit the Preventive Controls set on a higher level.

Unfortunately this inheritance does not occur for Detective and Proactive Controls. As AWS continues releasing the Controls and your environment might me also expanding this can result in OUs not having the full range of neede OUs enabled. So in case you don’t want to generate an overhead when trying to activate the Controls on every underlying OU, just keep reading to see how I resolved this issue.

Solving the Problem

The infrastructure is built as shown in the picture below. The main actions are implemented with the usage of a AWS Step Function

We have two main topics to take a look here:

Inherit activated Controls to all underlying OUs
Making sure new OUs and accounts also get the corresponding Controls

Let’s look at Step 1 first:

First of all is to make sure we have a place to document all the Controls we want to activate in our environment. I used the SSM Parameter store as it lets you save values in a JSON format which we will work with in this solution. This Control list is set in the Cloudformation code and then deployed to the parameter store.

As soon as a change happens to this parameter in the code a Lambda Custom Resource gets triggered. Custom Resources in Cloudformation are mostly connected with a Lambda function which gets executes as soon as the Custom Resource gets updated. So in case we update our Control List later, the Lambda function gets executed. The function the starts the execution of a Step Function which is used to enable all the Controls on all OUs in the following way.

The step function first executes a parallel state:

First State: Reading out the SSM Parameter value by using the GetParameter API call and transforming the JSON to an array with a separate Lambda function. This is done to let the Step Function be able to loop over the different Control values set in the Parameter Store.
Second State: Execute a Lambda function reading out all of OUs of the organization. In case an OU should be left out, it will not be part of the output here.

Both outputs are passed to the following Map State which then first loops over all Controls which were read out earlier from the parameter store.

An inner loop then loops over all OUs followed by a Pass State combining the Control value and the OU value. This will get passed to the EnableControl API call to activate the Control to the corresponding OU. Unfortunately as the automation runs in to an error in case the Control has already been activated an catch expression was inserted here to not let the Step Function fail and continue with the next OU.

The Map States then loop over every Control and over every OU making sure all combinations were handled.

But how do we make sure that also newly created OUs will get the Controls?

This is done in Step 2:

For this case we just need to implement an EventBridge rule listening to the ManageOrganizationalUnit CloudTrail event, handing this over to the Step function used above. As Control Tower takes some time to also register the OU and rolling out all necessary stacks a Wait State is set in the beginning of the Step Function. This makes sure that all prior needed steps are already finished when the Control Rollout takes place.

How to deploy

Check out my Github for all necessary code to this solution!

Of course the code should be deployed on the account where Control Tower has been activated. When deploying the template you will need to insert the Controls in an ARN format, divided by commata as seen in the screenshot below. As SSM Parameter Store saves everything as a String, make sure to not forget the apostrophes

During the deployment the Custom Resource will already get triggered, so take a look at the Step Function to see how the Controls are getting enabled!

About Me

Hi! My name is Jana, I live in the Southwest of Germany and when I'm not smashing weights in the gym I love to architect solutions in AWS making my and the customers lives easier.

I enjoy to learn and as the AWS portfolio is evolving all the time, I also try to stay up to date by getting certified and checking out newly launched products and services.

If you want to lift your environment either to the cloud or want to leverage your already migrated environment to use more of the cloud services, hit me up or check out Public Cloud Group GmbH!

If you want to support me, you can buy me a coffee!

About PCG

Public Cloud Group supports companies in their digital transformation through the use of public cloud solutions.

AWS Automatically Accept Transit Gateway Attachments for allowed CIDR and Account pairs

Jana Hockenberger — Mon, 28 Oct 2024 11:49:27 +0000

This solution will provide an approach to automatically accept Transit Gateway attachments by checking a centrally managed list of allowed CIDR and AccountId value pairs when using a centralized Transit Gateway.

Prerequisite for this solution is the existence of a centralized Transit Gateway which is shared with all accounts via Resource Access Manager.

Problems when creating a Transit Gateway

When creating a Transit Gateway you are offered the option to AutoAcceptSharedAttachments which means that if any account that uses the centralized Transit Gateway creates an attachment, it is automatically accepted.
Which in turn means that if we do not activate this feature we would have to manually accept all created Transit Gateway attachments. Depending on the size of your environment this could lead to a great overhead wasting valuable time resources.

Also probably not all created Transit Gateway Attachments are wanted but just a defined list of CIDR Blocks and Account IDs should be allowed to communicate with all VPCs and with the On-Premise datacenter.

So what if we just want an AutoAccept for specific CIDR blocks we defined prior? Then this solution will help you!

Overview over the Solution

This solution uses a DynamoDB table to manage the list of allowed CIDR Blocks and Account Ids pairs. Using cidr_block as the primary key makes sure to not include the same CIDR Block multiple times in the Transit Gateway Attachments. As one account can include multiple VPCs with Transit Gateway attachments, setting it as the primary key wouldn't be suitable here.

The values of the DynamoDB Table are set in the code in a Custom Resource which is used to initialize the DynamoDB Table. The Custom Resource executes a Lambda function during deployment or when the stack changes and creates the values for the DynamoDB Table which are documented in the code.

Also in every account an EventBridge Rule gets created which sends an event to the default base as soon as it captures the CloudTrail event CreateTransitGatewayVpcAttachment. The default bus of the corresponding account sends the event to the account where the Transit Gateway is created and triggers an Eventbridge Rule there which executes a Lambda Function.
As well a cross-account Lambda Role gets created in every account to read-out the CIDR Block of the VPC mentioned in the event.

The Lambda function then checks if an entry for the provided CIDR Block and Account Id exists in the DynamoDB table and accepts the Attachment when a match is found.

Deployment Steps

The solutions consists of two stacks.

The tgw-attach-auto-accept-core.yaml file needs to be created in the Account where the Transit Gateway is located.
The following resources will be created in the first stack:

A DynamoDB Table for the entries of allowed CIDR Blocks and Account Ids. The CIDR Block functions as the primary key.

TGWAttachmentDynamoDB:
    Type: 'AWS::DynamoDB::Table'
    Properties:
      TableName: 'TGWAttachmentAcceptedCIDR'
      AttributeDefinitions:
        - AttributeName: 'cidr_block'
          AttributeType: 'S'
        - AttributeName: 'account_id'
          AttributeType: 'S'
      KeySchema:
        - AttributeName: 'cidr_block'
          KeyType: 'HASH'  
        - AttributeName: 'account_id'
          KeyType: 'RANGE' 
      BillingMode: PAY_PER_REQUEST

A Custom Resources to initialize the DynamoDB Table entries and set the values. Every time the list of values in the Custom Resource gets updated, the Lambda Function will be executed again to update the DynamoDB Table.

DynamoDBTableInitializer:
    Type: Custom::DynamoDBTableInitializer
    Properties: 
      ServiceToken: !GetAtt TableInitializerFunction.Arn
      TableName: !Ref TGWAttachmentDynamoDB
      TableItems:
        - cidr_block: "1.2.3.4/5"
          account_id: "123456789012"
        - cidr_block: "6.7.8.9/12"
          account_id: "234567890123"
        ### more entries can be added here

  TableInitializerFunction:
    Type: AWS::Lambda::Function
    Properties: 
      Code:
        ZipFile: |
          import json
          import boto3
          import cfnresponse

          def lambda_handler(event, context):
              try:
                  table_name = event['ResourceProperties']['TableName']
                  items = event['ResourceProperties']['TableItems']

                  dynamodb = boto3.resource('dynamodb')
                  table = dynamodb.Table(table_name)

                  for item in items:
                      table.put_item(Item=item)

                  response_data = {'Status': 'Success'}
                  cfnresponse.send(event, context, cfnresponse.SUCCESS, response_data)
              except Exception as e:
                  response_data = {'Status': str(e)}
                  cfnresponse.send(event, context, cfnresponse.FAILED, response_data)
      Handler: 'index.lambda_handler'
      Runtime: python3.11
      Role: !GetAtt TableInitializerFunctionRole.Arn

An Eventbridge Rule which receives the "CreateTransitGatewayVpcAttachment" event from the default bus and triggers the Lambda function to check and accept the attachment.

CloudWatchRule:
    Type: "AWS::Events::Rule"
    Properties:
      Description: "Accepts the TGW Attachment and sets a Route in the Route Table to OnP-remise"
      State: ENABLED
      EventPattern: {
        "source": [
          "aws.ec2"
        ],
        "detail-type": [
          "AWS API Call via CloudTrail"
        ],
        "detail": {
          "eventSource": [
            "ec2.amazonaws.com"
          ],
          "eventName": [
            "CreateTransitGatewayVpcAttachment"
          ]
        }
      }
      Name: TGWAcceptAutoAttach
      Targets:
      - Arn: !GetAtt LambdaFunction.Arn
        Id: LambdaFunction

A Lambda Function to check the source account which created the attachment, read out the DynamoDB table and if required accept the Transit Gateway Attachment (code in Github).

After that the tgw-attach-auto-accept-global.yaml needs to be executed in all accounts, deploying it as a Stackset is recommended. This will create the following resources:

An Eventbridge Rule to capture CreateTransitGatewayVpcAttachment CloudTrail events from the specific accounts.

TGWAttachAutoAcceptRule:
    Type: "AWS::Events::Rule"
    Condition: IsNotTGWAccount
    Properties: 
      Description: CloudWatch Event Rule for automatically accepting TGW Attachments
      EventPattern: {
        "source": [ 
          "aws.ec2"
        ], 
        "detail-type": [ 
          "AWS API Call via CloudTrail" 
        ], 
        "detail": { 
          "eventSource": [ 
            "ec2.amazonaws.com" 
          ], 
          "eventName": [
            "CreateTransitGatewayVpcAttachment"
          ] 
        } 
      } 
      Name: "RuleForTGWAttachAutoAccept"
      Targets: 
        - Arn: !Sub "arn:aws:events:${AWS::Region}:${TgwAccount}:event-bus/default"
          Id: "TGWAttachAutoAcceptRule"
          RoleArn: !GetAtt TGWAttachAutoAcceptRole.Arn

A Cross-Account IAM Role to read-out the CIDR Block from the corresponding VPC which is given in the event

CrossAccountLambdaRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: CrossAccountLambdaRole
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Principal:
              AWS:
                - !Sub 'arn:aws:iam::${TgwAccount}:root'
            Action:
              - sts:AssumeRole
      MaxSessionDuration: 3600
      Path: /
      Policies:
        - PolicyName: CrossAccountLambdaRolePolicy
          PolicyDocument: 
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - ec2:DescribeVpcs
                Resource: "*"
              - Effect: Allow
                Action:
                  - iam:PassRole
                Resource: 'arn:aws:iam::*:role/*'

After the successful deployment and adding the relevant CIDR Block and Account Id pairs, you should be able to see the Transitgateway Attachment gets enabled automatically!

The complete solution is accessible in Github.

About Me

Hi! My name is Jana, I live in the Southwest of Germany and when I'm not smashing weights in the gym I love to architect solutions in AWS making my and the customers lives easier.

I enjoy to learn and as the AWS portfolio is evolving all the time, I also try to stay up to date by getting certified and checking out newly launched products and services.

If you want to lift your environment either to the cloud or want to leverage your already migrated environment to use more of the cloud services, hit me up or check out Public Cloud Group GmbH!

If you want to support me, you can buy me a coffee!

About PCG

Public Cloud Group supports companies in their digital transformation through the use of public cloud solutions.