Introduction

In my previous blog, Improving Contact Center Efficiency with Real-Time Queue Monitoring and Automation in AWS, I discussed the high-level architecture of a solution that monitors and controls queue activity in Amazon Connect.

‍

In this follow-up, I’ll walk you through deploying this type of solution using the ‘AWS Cloud Development Kit (CDK)’ and demonstrate the value that this can bring to your organization or development team. The CDK is especially useful for solutions where rapid iteration, repeatable infrastructure, and multi-environment deployments are critical.

‍

Overview of the CDK

What is it?

The AWS Cloud Development Kit (CDK) is an open-source software development framework that allows developers to define cloud infrastructure using familiar programming languages such as TypeScript, Python, Java, and C#. Instead of manually writing CloudFormation templates to provision resources, you can leverage high-level constructs to define and deploy AWS resources in a more maintainable and scalable manner.

‍

The CDK contains two primary components:

• AWS CDK Construct Library: Collection of pre-written modular and reusable pieces of code. These reusable ‘Constructs’ can be used to quickly integrate and develop infrastructure.
• AWS CDK Command Line Interface: A command line tool for interacting with CDK apps. This is also known as the ‘CDK Toolkit’

Benefits

There are numerous benefits that can be realized by using the CDK:

• Code-based Infrastructure – Easily track infrastructure changes over time through version control systems like Git.
• Reusability and Modularity – The CDK encourages the use of constructs, which are reusable building blocks of infrastructure. This makes it easy to standardize deployments, avoid duplicated configuration, and manual deployment errors.
• Simplified CloudFormation Management – Rather than writing raw CloudFormation YAML or JSON, the CDK lets you define the infrastructure using a high-level programming language, making it easier to read, maintain, and extend.
• Easier environment management – With native support for multi-environment deployments, CDK helps you manage different stages (dev, test, prod) with environment-specific configuration, without duplicating code.
• Automate deployments and increase efficiencies – The CDK integrates well with CI/CD pipelines, enabling faster iteration, automated rollouts, and better alignment between development and infrastructure teams.

Considerations

While the AWS CDK is a great tool to implement in your organization, there are some important considerations to make prior to committing to the tool:

• Learning Curve: Developers must be familiar with both AWS and the programming language supported in CDK.
• CloudFormation: While CDK simplifies the infrastructure as code, changes still rely on CloudFormation deployments.
• IAM Permissions: Proper IAM Permissions are required to deploy and manage AWS resources.
• State Management: The CDK manages state using AWS CloudFormation stacks and stores synthesized templates and metadata in an S3 bucket created during bootstrapping. If resources are changed outside of the CDK, the stack may drift, which can lead to deployment errors or unexpected behavior.

Permissions

IAM for CDK is tricky because the toolkit performs lookups, bootstraps, deploys, and asset uploads — each requiring different sets of permissions. AWS doesn’t yet provide a definitive least-privilege guide, so trial and error is often required.

‍

The following is a curated list of the minimum required IAM permissions for deploying a Lambda-based solution using AWS CDK. These were determined through hands-on testing.

‍

IAM Best Practice

Before we cover specific permissions, it is important to follow these best practices:

• Least privilege: Grant users and services with the least amount of permissions need to perform their job function
• Grouping permission for easy audit: By grouping permission sets into different Sids (Statement IDs) in your IAM policies and documentation, you make it easier to debug permission issues and perform audits later.

Lambda

These permissions allow CDK to create, update, configure, and manage Lambda functions. They're essential for defining function code, environment variables, and associating triggers like EventBridge or S3.

• lambda:CreateFunction
•  lambda:UpdateFunctionCode
• lambda:UpdateFunctionConfiguration
• lambda:GetFunction
• lambda:DeleteFunction
• lambda:AddPermission
• lambda:RemovePermission
• lambda:TagResource

Logs and Metrics

When a Lambda is deployed, CDK sets up logging through CloudWatch Logs automatically. These permissions ensure log groups and streams are created, and application logs are ingested.

• logs:CreateLogGroup
• logs:CreateLogStream
• logs:PutLogEvents
• logs:DescribeLogGroups
• cloudwatch:PutMetricData

Pass Role to Lambda

Lambda needs to run under an IAM execution role. This permission allows CDK to attach a pre-created role to the Lambda function.

• iam:PassRole
  
  • Scoped with a condition to ensure it’s only passed to ‘lambda.amazonaws.com’

SSM

These permissions are required even if you're not explicitly defining SSM parameters in your CDK stack. CDK may use Parameter Store behind the scenes to retrieve context or environment metadata, especially during bootstrapping or when resolving environment-specific details. These parameters are not created by your code, but CDK may read or write them internally as part of the deployment process.

• ssm:PutParameter
• ssm:GetParameter
• ssm:GetParameters
• ssm:DeleteParameter

ECR

These permissions are needed for the CDK to manage repositories used during asset bundling. Even if you're deploying standard Lambda functions (not container images), CDK may still generate and store Docker-based assets internally. These permissions ensure that CDK can create, configure, and clean up ECR repositories that are used as part of the Lambda deployment workflow.

• ecr:CreateRepository
• ecr:DescribeRepositories
• ecr:DeleteRepository
• ecr:SetRepositoryPolicy
• ecr:GetLifecyclePolicy
• ecr:PutImageScanningConfiguration
• ecr:PutLifecyclePolicy

CloudFormation

CDK synthesizes and deploys CloudFormation templates under the hood. These permissions are necessary for stack management and visibility in the AWS Console.

• cloudformation:DescribeStacks
• cloudformation:GetTemplate
• cloudformation:DescribeStackEvents
• cloudformation:CreateStack
• cloudformation:UpdateStack
• cloudformation:DeleteStack
• cloudformation:CreateChangeSet
• cloudformation:DescribeChangeSet
• cloudformation:ExecuteChangeSet
• cloudformation:ListStacks
• cloudformation:ListStackResources

S3

The CDK uses a bootstrapped S3 bucket to store synthesized assets (e.g., Lambda ZIP files). These permissions enable CDK to upload and reference those artifacts during deployment.

• s3:GetObject
• s3:PutObject
• s3:ListBucket
• s3: PutEncryptionConfiguration
• s3:PutBucketVersioning
• s3:PutBucketPublicAccessBlock
• s3:GetBucketPublicAccessBlock
• s3:PutBucketPolicy
• s3:DeleteBucketPolicy
• (Optional: s3:DeleteObject if your app or CDK cleans up assets)

Example IAM Policy for CDK Deployment

To simplify deployment and avoid trial-and-error during setup, here’s a complete IAM policy that includes the minimum permissions needed to deploy a Lambda-based solution using the AWS CDK.

This policy has been tested in a real-world environment and is intended as a starting point. It follows best practices by grouping permissions by service using Sid blocks, and it includes coverage for services typically involved in deploying Lambda with CDK — such as IAM, CloudFormation, S3, ECR, CloudWatch Logs, and SSM.

‍

Notes:

• This policy is intended only for CDK deployment operations. It does not include runtime permissions for the Lambda function (e.g., access to EventBridge, SNS, DynamoDB, or SES). Those permissions must be assigned to the Lambda’s execution role, not the CDK deployment role.
• This is not an exhaustive policy for all CDK use cases. It is scoped specifically for deploying Lambda functions and their supporting infrastructure.
• EventBridge permissions are included as part of the architecture from my previous blog post. If your implementation doesn’t require it, you can safely remove this section

Conclusion

Getting IAM permissions right is a foundational step when deploying with the AWS CDK. In this post, we walked through a minimal deployment policy tailored for Lambda-based solutions, along with best practices for structuring IAM access. Taking the time to get your deployment permissions right – and separating them from your runtime execution roles – can save hours of debugging and confusion down the line.

‍

In Part 2, we’ll dive into initializing your CDK app, organizing your project structure, and deploying your stack with real world examples. Stay tuned!

‍

~ Steven Cook