Pulumi Blog: Aws cdk

Announcing the 1.0 release of AWS CDK on Pulumi

Matt Jeffryes — Mon, 02 Dec 2024 08:00:00 -0700

At Pulumi, we’re committed to delivering the widest range of cloud infrastructure building blocks for use in your cloud engineering projects. In 2022, we introduced preview support for integrating AWS CDK constructs into Pulumi programs and today we’re happy to announce the 1.0 release of our pulumi-cdk library for typescript. This first stable version completes support for common CDK features enabling you to deploy almost any CDK construct with Pulumi.

The pulumi-cdk library provides access to the many high-level libraries (‘constructs’) built by service teams at AWS and by the AWS CDK community. However, there were some limitations in the preview version of the library that prevented using some constructs and complicating migration of existing CDK stacks. Uncertainty about which constructs were supported has limited adoption of this rich ecosystem by Pulumi users.

With the new 1.0 release, pulumi-cdk has greatly expanded compatibility with all CDK features. Users can now confidently use Pulumi to deploy constructs they have written themselves or any of the 1600+ constructs in AWS’s construct hub. We’re excited to bring Pulumi users access to all the high level interfaces curated by AWS and the CDK community.

Additionally, existing AWS CDK users now have an easier path to transition from CloudFormation to Pulumi, unlocking faster deployments, integration with Pulumi’s vast provider ecosystem and all of the features of Pulumi’s Cloud Engineering Platform (like Policy as Code, Audit Logs, Drift detection, Secrets, and much more).

Deploying CDK Constructs with Pulumi

To deploy existing AWS CDK Constructs using Pulumi:

Create a class that derives from pulumicdk.Stack (which itself is derived from awscdk.Stack).
In the constructor, use any AWS CDK constructs from existing libraries such as aws-cdk-lib
Create a pulumicdk.App instance that constructs an instance of your stack.

For example, the following program deploys an AWS Apprunner CDK Construct using Pulumi:

import * as pulumi from '@pulumi/pulumi';
import * as pulumicdk from '@pulumi/cdk';
import { Service, Source } from '@aws-cdk/aws-apprunner-alpha';

class AppRunnerStack extends pulumicdk.Stack {
 url: pulumi.Output<string>;

 constructor(id: string, options?: pulumicdk.StackOptions) {
 super(id, options);

 const service = new Service(this, 'service', {
 source: Source.fromEcrPublic({
 imageConfiguration: { port: 8000 },
 imageIdentifier: 'public.ecr.aws/aws-containers/hello-app-runner:latest',
 }),
 });

 this.url = this.asOutput(service.serviceUrl);
 }
}

const app = new pulumicdk.App('app', (scope: pulumicdk.App): pulumicdk.AppOutputs => {
 const stack = new AppRunnerStack('teststack');
 return {
 url: stack.url,
 };
});
export const url = app.outputs['url'];

Deploy with a pulumi up:

> pulumi up

Updating (dev)

View Live: https://app.pulumi.com/lukehoban/pulumi-cdk-apprunner/dev/updates/1

 Type Name Status
 + pulumi:pulumi:Stack pulumi-cdk-apprunner-dev created
 + └─ cdk:index:StackComponent teststack created
 + └─ cdk:construct:Service teststack/adapter/service created
 + └─ aws-native:apprunner:Service service6D174F83 created

Outputs:
 url: "2ez3iazupm.us-west-2.awsapprunner.com"

Resources:
 + 4 created

And curl the endpoint:

> curl https://$(pulumi stack output url)

 ______ __ __ __ _ __
 / ____/___ ____ ____ __________ _/ /___ __/ /___ _/ /_(_)___ ____ _____/ /
 / / / __ \/ __ \/ __ `/ ___/ __ `/ __/ / / / / __ `/ __/ / __ \/ __ \/ ___/ /
/ /___/ /_/ / / / / /_/ / / / /_/ / /_/ /_/ / / /_/ / /_/ / /_/ / / / (__ )_/
\____/\____/_/ /_/\__, /_/ \__,_/\__/\__,_/_/\__,_/\__/_/\____/_/ /_/____(_)
 /____/

 Congratulations, your service has successfully deployed on AWS App Runner.

Open it in your browser at https://2ez3iazupm.us-west-2.awsapprunner.com/

Try the workshop at https://apprunnerworkshop.com
Read the docs at https://docs.aws.amazon.com/apprunner

Pulumi takes CDK apps to the next level

Combine CDK constructs with any of the features of Pulumi programs to deploy faster, easier and to any cloud. Use Pulumi functions and stack references to connect to pre-existing infrastructure and mix in resources from any provider to bring all of your infrastructure under management.

For example, we can use CDK’s ecs_patterns to quickly create a loadbalanced Fargate service, but route traffic to it with a record in an existing CloudFlare DNS zone.

import * as path from 'path';
import * as acm from 'aws-cdk-lib/aws-certificatemanager';
import * as aws from '@pulumi/aws';
import * as pulumi from '@pulumi/pulumi';
import * as pulumicdk from '@pulumi/cdk';
import * as cloudflare from '@pulumi/cloudflare';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as ecsPatterns from 'aws-cdk-lib/aws-ecs-patterns';

let config = new pulumi.Config();
let accountId = config.requireSecret("cloudflare_account_id");
let zoneName = config.require("cloudflare_zone_name");
let certificateId = config.require("certificate_id");
let certificateKey = config.requireSecret("certificate_key");

class CloudFlareStack extends pulumicdk.Stack {
 constructor(app: pulumicdk.App, id: string) {
 super(app, id);

 // First Load the zone and certificate from CloudFlare
 ///////////////////////////////////////////////////////

 // Read the CloudFlare zone for the domain
 const zone = cloudflare.getZoneOutput({
 accountId,
 name: zoneName,
 });

 // read the certificate from CloudFlare
 const caCertificate = cloudflare.getOriginCaCertificateOutput({
 id: certificateId,
 });

 // Import the certificate in ACM
 const cert = new aws.acm.Certificate('import', {
 privateKey: certificateKey,
 certificateBody: caCertificate.certificate,
 });

 // Create a L2 reference from the cert arn
 const acmCert = acm.Certificate.fromCertificateArn(this, 'cert', pulumicdk.asString(cert.arn));

 // Next, use ECS Patterns to create a loadbalanced fargate service with the correct certificate
 ///////////////////////////////////////////////////////////////////////////////////////////////

 const loadBalancedFargateService = new ecsPatterns.ApplicationLoadBalancedFargateService(this, 'Service', {
 certificate: acmCert,
 redirectHTTP: true,
 taskImageOptions: {
 image: ecs.ContainerImage.fromRegistry("amazon/amazon-ecs-sample"),
 },
 });

 const alb = loadBalancedFargateService.loadBalancer;

 // Finally, Create a record in CloudFlare that directs to the service's loadbalancer
 ////////////////////////////////////////////////////////////////////////////////////

 new cloudflare.Record('alb', {
 name: 'cdk-alb',
 type: 'CNAME',
 zoneId: zone.zoneId,
 content: this.asOutput(alb.loadBalancerDnsName),
 proxied: true,
 });
 }
}

class MyApp extends pulumicdk.App {
 constructor() {
 super('app', (scope: pulumicdk.App) => {
 new CloudFlareStack(scope, 'cloudflare');
 });
 }
}

new MyApp();

Pulumi let’s you read and create any resource type across thousands of different cloud service providers and integrate them with your CDK stacks. Building CDK apps on Pulumi brings a host of other benefits too, including:

Customize resource options (eg. to protect a database against accidental deletion or deploy to multiple regions in the same program)
Detect and manage drift with Pulumi deployments
Track and store user actions and change history with Audit Logs
And a host of other benefits from Pulumi Cloud

Expanded Features in pulumi-cdk 1.0

The 1.0 version of pulumi-cdk adds support for key CDK features such as: assets, custom resources, nested stacks, and aspects, so most existing CDK constructs will work with Pulumi without any modification. We’ve also eliminated the need to call cdk bootstrap before running pulumi up by integrating a custom Pulumi Synthesizer.

Using CDK Aspects

Pulumi CDK now supports CDK aspects. For example, you can add the cdk-nag aspect to your stack to enforce best practices:

import * as pulumicdk from '@pulumi/cdk';
import * as s3 from 'aws-cdk-lib/aws-s3';
import { AwsSolutionsChecks } from 'cdk-nag';

const app = new pulumicdk.App('app', (scope: pulumicdk.App): pulumicdk.AppOutputs => {
 const stack = new pulumicdk.Stack('example-stack');
 Aspects.of(stack).add(new AwsSolutionsChecks({ verbose: true }));

 new s3.Bucket(this, 'bucket');
});

Example Output

[Error at /test-stack/bucket/Resource] AwsSolutions-S1: The S3 Bucket has server access logs disabled. The bucket should have server access logging enabled to provide detailed records for the requests that are made to the bucket.
[Error at /test-stack/bucket/Resource] AwsSolutions-S10: The S3 Bucket or bucket policy does not require requests to use SSL. You can use HTTPS (TLS) to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. You should allow only encrypted connections over HTTPS (TLS) using the aws:SecureTransport condition on Amazon S3 bucket policies.

CDK assets

CDK’s assets make it easy to bundle code and other files your application needs into an S3 bucket or a Docker container, eliminating extra steps from your build pipeline. For example you can use Docker container asset to deploy a Fargate service from local directory. CDK will build the container image and push to ECR on pulumi up.

import * as pulumicdk from '@pulumi/cdk';
import * as aws from '@pulumi/aws';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as ecs_patterns from 'aws-cdk-lib/aws-ecs-patterns';

const app = new pulumicdk.App('app', (scope: pulumicdk.App) => {
 const stack = new pulumicdk.Stack('example-stack');

 const vpc = new ec2.Vpc(stack, 'MyVpc');
 const cluster = new ecs.Cluster(stack, 'fargate-service-autoscaling', { vpc });

 // Create Fargate Service
 const fargateService = new ecs_patterns.NetworkLoadBalancedFargateService(this, 'sample-app', {
 cluster,
 taskImageOptions: {
 image: ecs.ContainerImage.fromAsset(path.join(__dirname, './'), {
 // assetName is required and is used in the name of the ecr repository that is created
 assetName: 'cdk-fargate-example',
 }),
 },
 });
});

Future direction

Currently AWS CDK on Pulumi is supported only for TypeScript users, but we’re eager to bring the benefits of the CDK ecosystem to all Pulumi languages in the future. You can comment and upvote on this tracking issue, to let us know this is important to you.

We’re also exploring options for importing state from CDK applications that are already deployed with CloudFormation to enable seamless migration for existing CDK users. Please let us know on this tracking issue if you would be interested in testing this with us.

Summary

The 1.0 release of AWS CDK support for Pulumi marks a significant expansion of opportunities to interoperate between the AWS CDK and Pulumi ecosystems. Existing AWS CDK users can now more easily adopt the full power, speed and flexibility of the Pulumi Cloud Platform and its diverse ecosystem. And existing Pulumi users can benefit from the many expert curated constructs and libraries in the CDK community. We’re excited to see what you’ll build with these two great cloud technologies together.

The AWS CDK on Pulumi project is open source at https://github.com/pulumi/pulumi-cdk and on NPM at https://www.npmjs.com/package/@pulumi/cdk. Get started today!

AWS CDK vs Pulumi: Why SST Chose Pulumi

Sara Huddleston — Wed, 25 Sep 2024 07:32:40 +0000

Cloud computing tools evolve, and so must the frameworks developers rely on. For SST (Serverless Stack), AWS CDK was a great starting point—but it had limitations.

CDK tied infrastructure to AWS.
Debugging was frustrating due to CloudFormation templates.
Multi-cloud was nearly impossible.

The solution? Pulumi. In this post, we’ll explore why SST moved to Pulumi, what challenges they overcame, and what this means for developers building modern cloud applications.

TL;DR: Pulumi lets SST offer a faster, more flexible, and provider-agnostic infrastructure experience.

The Beginnings of SST

Application developers have witnessed the rapid evolution of cloud computing and the growing need for developers to have direct access to powerful cloud resources. However, the traditional tools and approaches to Infrastructure as Code (IaC) have often been geared more toward DevOps teams, leaving application developers feeling disconnected from the infrastructure side of their projects.

This was the driving force behind the creation of SST (Serverless Stack), a framework that aims to bridge the gap between application developers and infrastructure management. In the early days, SST was built on top of AWS’s Cloud Development Kit (CDK), which allowed developers to define their infrastructure using TypeScript or Python. While this was a step in the right direction, they soon realized that the limitations of CDK and the underlying AWS CloudFormation were holding them back from truly empowering application developers.

CDK and CloudFormation Limitations

As the SST’s team continued to work with CDK and CloudFormation, they encountered several challenges that led them to reevaluate their approach. One key issue was the disconnect between application developers’ thinking and working and traditional IaC tools’ operating methods.

With CDK and CloudFormation, the infrastructure code is essentially a code generator, producing an intermediary format (such as YAML or JSON) that is then executed to deploy the resources. This means that the actual code you write as a developer is not the same as the code running during the deployment process. This can lead to several problems, such as difficulty debugging, lack of visibility into the deployment process, and challenges in extending or customizing the deployment workflow.

Additionally, as the SST’s team expanded its focus beyond the AWS ecosystem and started exploring other cloud providers and even on-premises infrastructure, it found that the AWS-centric nature of CDK and CloudFormation was becoming a limitation. It needed a more flexible and provider-agnostic solution that would allow it to deploy and manage infrastructure across a wide range of platforms.

Feature	AWS CDK	Pulumi
Multi-Cloud Support	❌ AWS-Only	✅ AWS, Azure, GCP, On-Prem
Debugging	❌ Hard due to CloudFormation	✅ Real-time debugging
Language Support	⚠️ TypeScript, Python	✅ Any programming language
Deployment Speed	❌ Slower due to CloudFormation	✅ Faster direct execution
Visibility	❌ Hard to trace errors	✅ Clear deployment state
Extensibility	⚠️ Limited to AWS ecosystem	✅ Custom providers & workflows
State Management	❌ CloudFormation state file	✅ Pulumi-managed state
Secrets Management	❌ AWS Secrets Manager only	✅ Cross-cloud secret support

A Provider-agnostic Solution: Discovering Pulumi

It was during this time that the SST team discovered Pulumi, a modern IaC platform that takes a fundamentally different approach to infrastructure management. Instead of generating an intermediary format, Pulumi treats the infrastructure code as a first-class program executed directly during deployment.

This paradigm shift had several important implications for SST and its users:

Visibility and Extensibility: With Pulumi, the infrastructure code is the same code that is running during deployment, which means there is much greater visibility into the deployment process and the ability to extend or customize it as needed.
Multi-Cloud Capabilities: Pulumi’s provider-agnostic approach allows SST’s team to easily work with a wide range of cloud and on-premises platforms, giving their users the flexibility to deploy their infrastructure wherever it makes the most sense for their application.
Simplified Mental Model: For application developers, the Pulumi model of “your code is the deployment” aligns much more closely with their existing mental models and workflows, making it easier for them to adopt and work with IaC tools.

Transitioning to Pulumi

Transitioning SST from CDK to Pulumi was not a trivial undertaking. Still, they knew it was a necessary step to truly fulfill their mission of empowering application developers with powerful infrastructure management capabilities.

One key challenge they faced was re-implementing the higher-level components and abstractions they had built on top of CDK. These components were designed to simplify the infrastructure management experience for their users, and they wanted to ensure that they could provide a similar level of abstraction and ease of use with Pulumi.

Additionally, they had to carefully consider how to handle the various edge cases and complex deployment scenarios their users encountered with the CDK-based version of SST. They wanted to ensure that the Pulumi-based version would not only match the functionality of the previous version but also improve upon it and address some of the limitations they had encountered.

The Benefits of Pulumi

As they worked through the transition to Pulumi, they realized the significant benefits that Pulumi offered to both the SST team as the framework developers and the users.

Improved Visibility and Debugging

One of Pulumi’s most immediate and tangible benefits was the improved visibility and debugging capabilities it provided. With the infrastructure code being the same as the deployment code, they could easily trace issues back to the source and understand exactly what was happening during the deployment process.

This starkly contrasted the CDK/CloudFormation approach, where the intermediary format (CloudFormation templates) often obscured the underlying logic and made it much more difficult to diagnose and resolve problems.

Extensibility and Customization

Pulumi’s design also allowed the SST team to easily extend and customize the deployment process to meet the specific needs of their users. They could leverage Pulumi’s built-in extensibility features, such as custom providers and dynamic components, to integrate with a wide range of cloud and on-premises services and implement complex deployment workflows tailored to our users’ requirements.

This level of customization was much more challenging with the CDK/CloudFormation approach, where they often had to resort to hacky workarounds or custom Lambda functions to achieve the desired functionality.

Multi-Cloud Capabilities

As mentioned earlier, one key driver for their transition to Pulumi was the need to support a wider range of cloud and on-premises platforms. With Pulumi’s provider-agnostic approach, the SST team was able to easily add support for new providers, allowing their users to deploy and manage infrastructure across a diverse set of environments.

This flexibility has been particularly valuable for their users, who may have workloads or requirements that span multiple cloud providers or even on-premises infrastructure. With SST built on Pulumi, they can now manage all of their infrastructure through a single, consistent interface without having to juggle multiple tools or approaches.

Simplified Mental Model

One of Pulumi’s most significant benefits for SST users is the simplified mental model it provides. By treating the infrastructure code as a first-class program, Pulumi aligns much more closely with how application developers think and work.

Instead of having to navigate the complexities of intermediary formats, deployment pipelines, and the separation between infrastructure code and deployment code, SST users can now focus on writing their infrastructure logic in the same programming languages they use for their application code. This makes it much easier for them to understand, maintain, and extend their infrastructure as their needs evolve.

Build across any cloud with Pulumi

Define your infrastructure in TypeScript, Python, Go, or C#, and deploy it across AWS, Azure, Google Cloud, and on-premises environments from one consistent workflow.

Get started

The Future of SST with Pulumi

With Pulumi’s foundation in place, they can now focus on further enhancing the developer experience and expanding the capabilities of their framework. Some of the key areas they are exploring include:

Deeper Integration with Application Frameworks: By leveraging Pulumi’s flexibility, they can create even tighter integrations between SST and the application frameworks and libraries that their users rely on, making managing infrastructure seamless alongside their application code.
Expanded Provider Support: the SST team will continue to add support for a wide range of cloud and on-premises providers, ensuring that their users can deploy and manage their infrastructure wherever it makes the most sense for their needs.
Improved Deployment Workflows: Building on Pulumi’s extensibility, they can create more advanced deployment workflows that address the specific needs of application developers, such as faster deployment times, better rollback capabilities, and more granular control over the deployment process.
Enhanced Observability and Monitoring: By treating the infrastructure code as a first-class program, they can provide their users with better visibility into the deployment process and more robust monitoring and observability capabilities, helping them to identify and resolve issues quickly.

As the SST team continues to evolve with Pulumi at its core, they aim to deliver an even more powerful and user-friendly infrastructure management experience for developers. This will empower teams to focus on building great applications while effortlessly managing the underlying infrastructure.

Conclusion

If you’re interested in exploring Pulumi further, here are several ways to get involved:

Discover how Pulumi Crosswalk for AWS simplifies “day one” tasks in our AWS guide
Watch our on-demand workshop Getting Stated with Infrastructure as Code on AWS
Register for one of our upcoming Platform Engineering or DevOps workshops
But most importantly, try Pulumi today!

Frequently Asked Questions

What is SST?

SST is a framework that makes building modern full-stack applications on your infrastructure easy.

What is SST’s Ion?

Ion is the code name for a new engine for deploying SST applications. The constructs (or components) are deployed using Pulumi instead of CDK and CloudFormation (CFN). Once Ion is stable, it will be released as SST v3.

Does SST use mostly Terraform or Pulumi?

SST leverages Pulumi behind the scenes for its providers and deployment engine while also bridging Terraform providers through Pulumi.

How does SST make money?

SST (Serverless Stack) makes money primarily through its managed service, called SST Console. The Console is optional and includes a free tier. In short, SST primarily relies on SaaS (Software as a Service) revenue through its managed platform and potentially supplemental income streams like enterprise services and consulting.

Introducing AWS CDK on Pulumi

Luke Hoban — Wed, 04 May 2022 06:56:00 -0700

This blog post contains outdated information. For the latest features, updates, and examples, see our latest release: AWS CDK on Pulumi 1.0.

One of our key goals with Pulumi’s Universal Infrastructure as Code platform is to offer access to the widest range of cloud infrastructure building blocks for use within your cloud engineering projects. Over the years, that has led us to support interoperating seamlessly with a variety of alternative infrastructure definition formats, like Helm, CloudFormation, Azure Resource Manager and Kubernetes YAML. Today we’re really excited to add support for AWS CDK constructs to the list!

The AWS Cloud Development Kit (CDK) offers a large collection of higher-level libraries (“constructs”) for working with the AWS platform, built by service teams at AWS and by the AWS CDK community. These libraries are available in the same set of general purpose programming languages that Pulumi supports, with the primary difference being that AWS CDK compiles infrastructure programs into CloudFormation. This dependence on CloudFormation limits AWS CDK to being deployed via the CloudFormation deployment service which can slow down deployments and introduce some developer productivity friction due to the impedance mismatch between the program you write and the YAML it gets transpiled into.

With the new AWS CDK on Pulumi project, available in public preview today, we are opening up the ability to use AWS CDK constructs from within a Pulumi deployment. For users already using AWS CDK, this provides Pulumi as a new option for orchestrating deployments in place of CloudFormation, offering improved deployment speed, integration with the full set of features of the Pulumi Cloud Engineering Platform (like Policy as Code, Audit Logs, Secrets, and much more). And for Pulumi users, they are now able to leverage and benefit from the decades of experience AWS teams and the AWS CDK community have invested in designing well-architected infrastructure patterns through these constructs.

Even better, you can also now combine AWS CDK and Pulumi resources in a single Pulumi infrastructure as code project - passing outputs from Pulumi resources into AWS CDK constructs, and outputs from AWS CDK constructs into Pulumi resources. This allows you to work across the more than 80 cloud and SaaS providers that Pulumi offers access to, while still benefiting from high level libraries from the AWS CDK project, and without the hassles of a transpiler.

Deploying AWS CDK Constructs with Pulumi

To deploy existing AWS CDK Constructs using Pulumi, simply do the following:

Create a class that derives from pulumicdk.Stack (which itself is derived from awscdk.Stack).
In the constructor, use any AWS CDK constructs from existing libraries such as aws-cdk-lib
Call this.synth() to finalize the stack and deploy its resources.

Constructing an instance of this pulumicdk.Stack from within your Pulumi program will then deploy all of the infrastructure defined by the CDK constructs in the Stack using Pulumi.

For example, the following program deploys two AWS CDK Constructs using Pulumi.

import * as fs from 'fs';
import * as events from 'aws-cdk-lib/aws-events';
import * as events_targets from 'aws-cdk-lib/aws-events-targets';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import { Duration } from 'aws-cdk-lib';
import * as pulumicdk from '@pulumi/cdk';
import { remapCloudControlResource } from './adapter';

class LambdaStack extends pulumicdk.Stack {
 constructor(id: string, options?: pulumicdk.StackOptions) {
 super(id, { ...options, remapCloudControlResource });

 // Use the AWS CDK Lambda Function API directly.
 const lambdaFn = new lambda.Function(this, 'lambda', {
 code: new lambda.InlineCode(fs.readFileSync('lambda-handler.py', { encoding: 'utf-8' })),
 handler: 'index.main',
 timeout: Duration.seconds(300),
 runtime: lambda.Runtime.PYTHON_3_6,
 });

 // Use the AWS CDK Rule API directly.
 const rule = new events.Rule(this, 'rule', {
 // Run 6:00 PM UTC every Monday through Friday
 schedule: events.Schedule.expression('cron(0 18 ? * MON-FRI *)'),
 });

 // Use the AWS CDK to add a Rule target to trigger the Function.
 rule.addTarget(new events_targets.LambdaFunction(lambdaFn));

 // Finalize the stack and deploy its resources.
 this.synth();
 }
}

const stack = new LambdaStack('teststack');

This can be deployed with the pulumi CLI just like any other Pulumi program.

> pulumi up
Updating (dev)
View Live: https://app.pulumi.com/lukehoban/cdk-cron-lambda/dev/updates/37
Type Name Status
+ pulumi:pulumi:Stack cdk-cron-lambda-dev created
+ └─ cdk:index:Stack teststack created
+ └─ cdk:construct:LambdaStack teststack/teststack created
+ ├─ cdk:construct:Function teststack/teststack/lambda created
+ │ ├─ cdk:construct:Role teststack/teststack/lambda/ServiceRole created
+ │ │ └─ aws-native:iam:Role lambdaServiceRole494E4CA6 created
+ │ └─ aws-native:lambda:Function lambda8B5974B5 created
+ └─ cdk:construct:Rule teststack/teststack/rule created
+ ├─ aws:cloudwatch:EventRule ruleF2C1DCDC created
+ ├─ aws:cloudwatch:EventTarget Target0 created
+ └─ aws:lambda:Permission ruleAllowEventRuleteststacklambda47768855D6EFF36B created
Resources:
+ 11 created
Duration: 48s

We can see that each CDK Construct is shown in the Pulumi resource tree, and the leaf nodes of the deployment are the underlying AWS resources needed for this cloud infrastructure. Note that they are deployed via Pulumi, not via CloudFormation. This enables faster deployments, because Pulumi coordinates directly with AWS instead of going through CloudFormation, as well as the ability to use Pulumi features like pulumi logs, Policy as Code, and the features of the Pulumi Service.

Using AWS CDK Constructs Within Pulumi Programs

We can also combine the best of AWS CDK with the best of Pulumi, by using both Pulumi resources and AWS CDK Constructs in the same deployment. This enables combining rich AWS CDK Constructs with the breadth of the Pulumi ecosystem, including support for multiple cloud and SaaS providers.

The following example shows creating an AWS Lambda Function with the Pulumi AWS SDK, and then using an output of that Function (the arn) as an input to an AWS Events Rule CDK Construct. An output from the AWS CDK Construct is then converted to a Pulumi Output value which can be used in the rest of the Pulumi program - and in particular as a Pulumi Stack Output.

import * as events from 'aws-cdk-lib/aws-events';
import * as events_targets from 'aws-cdk-lib/aws-events-targets';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as pulumi from '@pulumi/pulumi';
import * as pulumicdk from '@pulumi/cdk';
import * as aws from '@pulumi/aws';
import { remapCloudControlResource } from './adapter';

// Create a resource in Pulumi
const fn = new aws.lambda.CallbackFunction('lambda', {
 callback: (ev, ctx) => console.log(JSON.stringify(ev)),
});

class LambdaStack extends pulumicdk.Stack {
 ruleArn: pulumi.Output<string>;

 constructor(id: string, options?: pulumicdk.StackOptions) {
 super(id, { ...options, remapCloudControlResource });

 // Use the AWS CDK Rule API directly.
 const rule = new events.Rule(this, 'rule', {
 // Run 6:00 PM UTC every Monday through Friday
 schedule: events.Schedule.expression('cron(0 18 ? * MON-FRI *)'),
 });

 // Get an AWS CDK Function instance from the Pulumi Lambda ARN.
 const lambdaFn = lambda.Function.fromFunctionArn(this, 'lambdaFn', pulumicdk.asString(fn.arn));

 // Use the AWS CDK to add a Rule target to trigger the Function.
 rule.addTarget(new events_targets.LambdaFunction(lambdaFn));

 // Export the Lambda function's ARN as an output.
 this.ruleArn = this.asOutput(rule.ruleArn);

 this.synth();
 }
}

const stack = new LambdaStack('teststack');
export const ruleArn = stack.ruleArn;

Note how the pulumicdk.asString and asOutput functions are used to convert Pulumi Outputs to AWS CDK Tokens and vice-versa to map values out of and into Pulumi.

Building on AWS Native and the AWS Cloud Control API

Last year we released a new AWS Native Pulumi provider in preview. The AWS Native provider builds on the new AWS Cloud Control API, which offers direct provisioning support for the same resource model supported by AWS CloudFormation.

The new AWS CDK on Pulumi builds upon AWS Native by converting the CloudFormation resource tree into the corresponding resource definitions from the AWS Native provider. This provides a high fidelity mapping of each resource into Pulumi. The coverage provided by AWS Cloud Control API (and thus AWS Native) is not yet complete across the entire breadth of the CloudFormation resource model though, so for some resources, it may be necessary to map them to a resource definition to use via the AWS provider. This is handled via the remapCloudControlResource API which allows providing a custom mapping for a given CloudFormation resource type which is not yet supported in Pulumi AWS Native and AWS Cloud Control.

For example, to provide a mapping for the AWS::Lambda::Permission resource type, define a function like the following:

export function remapCloudControlResource(
 element: CfnElement,
 logicalId: string,
 typeName: string,
 rawProps: any,
 options: pulumi.ResourceOptions,
): pulumi.CustomResource | undefined {
 const props = pulumicdk.interop.normalize(rawProps);
 switch (typeName) {
 case 'AWS::Lambda::Permission':
 return new aws.lambda.Permission(
 logicalId,
 {
 action: props['action'],
 function: props['functionName'],
 principal: props['principal'],
 sourceArn: props['sourceArn'] ?? undefined,
 },
 options,
 );
 }

 return undefined;
}

In many cases, this is not needed, as AWS CDK on Pulumi offers builtin support for remapping many common resources. Over the coming months, as AWS Cloud Control API support expands to cover more of the CloudFormation resource model, these remappings will become less necessary in practice, with almost all resources being supported directly via Pulumi AWS Native.

Use AWS CDK constructs with Pulumi

Deploy your existing AWS CDK constructs through Pulumi, and combine them with resources from hundreds of cloud and SaaS providers in a single program.

Learn more

Using High-Level “L3” Constructs

AWS CDK offers a mix of relatively low level (unopinionated) constructs, as well as high level (more opinionated) constructs. With AWS CDK on Pulumi, we can use any of these. This includes libraries like aws-ecs-patterns and AWS Solutions Constructs.

For example, to deploy a load balanced and auto-scaled Fargate service to a dedicated VPC, we can use the following program:

import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as pulumi from '@pulumi/pulumi';
import * as pulumicdk from '@pulumi/cdk';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as ecs_patterns from 'aws-cdk-lib/aws-ecs-patterns';
import { Construct } from 'constructs';
import { Stack, Duration, CfnOutput } from 'aws-cdk-lib';
import {remapCloudControlResource } from './adapter';

class FargateStack extends pulumicdk.Stack {

 loadBalancerDNS: pulumi.Output<string>;

 constructor(id: string, options?: pulumicdk.StackOptions) {
 super(id, { ...options, remapCloudControlResource });

 // Create VPC and Fargate Cluster
 const vpc = new ec2.Vpc(this, 'MyVpc', { maxAzs: 2 });
 const cluster = new ecs.Cluster(this, 'fargate-service-autoscaling', { vpc });

 // Create Fargate Service
 const fargateService = new ecs_patterns.NetworkLoadBalancedFargateService(this, 'sample-app', {
 cluster,
 taskImageOptions: {
 image: ecs.ContainerImage.fromRegistry("amazon/amazon-ecs-sample")
 },
 });

 // Setup AutoScaling policy
 const scaling = fargateService.service.autoScaleTaskCount({ maxCapacity: 2 });
 scaling.scaleOnCpuUtilization('CpuScaling', {
 targetUtilizationPercent: 50,
 scaleInCooldown: Duration.seconds(60),
 scaleOutCooldown: Duration.seconds(60)
 });

 this.loadBalancerDNS = this.asOutput(fargateService.loadBalancer.loadBalancerDnsName);

 // Finalize the stack and deploy its resources.
 this.synth();
 }
};

const stack = new FargateStack('fargatestack');
export const loadBalancerURL = stack.loadBalancerDNS;

Deploying this with pulumi up builds a few dozen AWS resources to construct the various building blocks necessary to capture this in raw AWS infrastructure:

> pulumi up

Updating (dev)

View Live: https://app.pulumi.com/lukehoban/pulumi-aws-cdk-fargate/dev/updates/1

 Type Name Status
 + pulumi:pulumi:Stack pulumi-aws-cdk-fargate-dev created
 + └─ cdk:index:Stack fargatestack created
 + └─ cdk:construct:FargateStack fargatestack/fargatestack created
 + ├─ cdk:construct:Cluster fargatestack/fargatestack/fargate-service-autoscaling created
 + │ └─ aws-native:ecs:Cluster fargateserviceautoscalingD107CF93 created
 + ├─ cdk:construct:NetworkLoadBalancedFargateService fargatestack/fargatestack/sample-app created
 + │ ├─ cdk:construct:FargateTaskDefinition fargatestack/fargatestack/sample-app/TaskDef created
 + │ │ ├─ cdk:construct:ContainerDefinition fargatestack/fargatestack/sample-app/TaskDef/web created
 + │ │ │ └─ cdk:construct:LogGroup fargatestack/fargatestack/sample-app/TaskDef/web/LogGroup created
 + │ │ │ └─ aws-native:logs:LogGroup sampleappTaskDefwebLogGroup34BE8C79 created
 + │ │ ├─ cdk:construct:Role fargatestack/fargatestack/sample-app/TaskDef/ExecutionRole created
 + │ │ │ ├─ cdk:construct:Policy fargatestack/fargatestack/sample-app/TaskDef/ExecutionRole/DefaultPolicy created
 + │ │ │ │ ├─ aws:iam:Policy sampleappTaskDefExecutionRoleDefaultPolicy0AD15374 created
 + │ │ │ │ └─ aws:iam:RolePolicyAttachment sampleappTaskDefExecutionRoleDefaultPolicy0AD15374-0 created
 + │ │ │ └─ aws-native:iam:Role sampleappTaskDefExecutionRoleAD6F4C40 created
 + │ │ ├─ cdk:construct:Role fargatestack/fargatestack/sample-app/TaskDef/TaskRole created
 + │ │ │ └─ aws-native:iam:Role sampleappTaskDefTaskRoleB530CAC0 created
 + │ │ └─ aws-native:ecs:TaskDefinition sampleappTaskDef6BF75736 created
 + │ ├─ cdk:construct:NetworkLoadBalancer fargatestack/fargatestack/sample-app/LB created
 + │ │ ├─ cdk:construct:NetworkListener fargatestack/fargatestack/sample-app/LB/PublicListener created
 + │ │ │ ├─ cdk:construct:NetworkTargetGroup fargatestack/fargatestack/sample-app/LB/PublicListener/ECSGroup created
 + │ │ │ │ └─ aws:lb:TargetGroup sampleappLBPublicListenerECSGroup525A567D created
 + │ │ │ └─ aws-native:elasticloadbalancingv2:Listener sampleappLBPublicListenerC4DF6480 created
 + │ │ └─ aws:lb:LoadBalancer sampleappLBBDE1D276 created
 + │ └─ cdk:construct:FargateService fargatestack/fargatestack/sample-app/Service created
 + │ ├─ cdk:construct:ScalableTaskCount fargatestack/fargatestack/sample-app/Service/TaskCount created
 + │ │ └─ cdk:construct:ScalableTarget fargatestack/fargatestack/sample-app/Service/TaskCount/Target created
 + │ │ ├─ cdk:construct:TargetTrackingScalingPolicy fargatestack/fargatestack/sample-app/Service/TaskCount/Target/CpuScaling created
 + │ │ │ └─ aws:appautoscaling:Policy sampleappServiceTaskCountTargetCpuScalingF4452F80 created
 + │ │ └─ aws:appautoscaling:Target sampleappServiceTaskCountTargetE827DC30 created
 + │ ├─ cdk:construct:SecurityGroup fargatestack/fargatestack/sample-app/Service/SecurityGroup created
 + │ │ └─ aws:ec2:SecurityGroup sampleappServiceSecurityGroup0ABF0D21 created
 + │ └─ aws-native:ecs:Service sampleappServiceE7504FDB created
 + └─ cdk:construct:Vpc fargatestack/fargatestack/MyVpc created
 + ├─ cdk:construct:PublicSubnet fargatestack/fargatestack/MyVpc/PublicSubnet2 created
 + │ ├─ aws:ec2:Eip MyVpcPublicSubnet2EIP8CCBA239 created
 + │ ├─ aws-native:ec2:Subnet MyVpcPublicSubnet2Subnet492B6BFB created
 + │ ├─ aws-native:ec2:RouteTable MyVpcPublicSubnet2RouteTable1DF17386 created
 + │ ├─ aws:ec2:NatGateway MyVpcPublicSubnet2NATGateway91BFBEC9 created
 + │ ├─ aws:ec2:Route MyVpcPublicSubnet2DefaultRoute052936F6 created
 + │ └─ aws-native:ec2:SubnetRouteTableAssociation MyVpcPublicSubnet2RouteTableAssociation227DE78D created
 + ├─ cdk:construct:PublicSubnet fargatestack/fargatestack/MyVpc/PublicSubnet1 created
 + │ ├─ aws:ec2:Eip MyVpcPublicSubnet1EIP096967CB created
 + │ ├─ aws-native:ec2:Subnet MyVpcPublicSubnet1SubnetF6608456 created
 + │ ├─ aws-native:ec2:RouteTable MyVpcPublicSubnet1RouteTableC46AB2F4 created
 + │ ├─ aws:ec2:NatGateway MyVpcPublicSubnet1NATGatewayAD3400C1 created
 + │ ├─ aws-native:ec2:SubnetRouteTableAssociation MyVpcPublicSubnet1RouteTableAssociation2ECEE1CB created
 + │ └─ aws:ec2:Route MyVpcPublicSubnet1DefaultRoute95FDF9EB created
 + ├─ cdk:construct:PrivateSubnet fargatestack/fargatestack/MyVpc/PrivateSubnet2 created
 + │ ├─ aws-native:ec2:RouteTable MyVpcPrivateSubnet2RouteTableCEDCEECE created
 + │ ├─ aws-native:ec2:Subnet MyVpcPrivateSubnet2Subnet0040C983 created
 + │ ├─ aws-native:ec2:SubnetRouteTableAssociation MyVpcPrivateSubnet2RouteTableAssociation86A610DA created
 + │ └─ aws:ec2:Route MyVpcPrivateSubnet2DefaultRoute9CE96294 created
 + ├─ cdk:construct:PrivateSubnet fargatestack/fargatestack/MyVpc/PrivateSubnet1 created
 + │ ├─ aws-native:ec2:RouteTable MyVpcPrivateSubnet1RouteTable8819E6E2 created
 + │ ├─ aws-native:ec2:Subnet MyVpcPrivateSubnet1Subnet5057CF7E created
 + │ ├─ aws-native:ec2:SubnetRouteTableAssociation MyVpcPrivateSubnet1RouteTableAssociation56D38C7E created
 + │ └─ aws:ec2:Route MyVpcPrivateSubnet1DefaultRouteA8CDE2FA created
 + ├─ aws-native:ec2:InternetGateway MyVpcIGW5C4A4F63 created
 + ├─ aws-native:ec2:VPC MyVpcF9F0CA6F created
 + └─ aws:ec2:InternetGatewayAttachment MyVpcVPCGW488ACE0D created

Outputs:
 loadBalancerURL: "sampleappLBBDE1D276-f412396-b0bebc132ad72c07.elb.us-west-2.amazonaws.com"

Resources:
 + 61 created

Duration: 4m51s

Future Directions

Currently AWS CDK on Pulumi is supported only for TypeScript users, due to how the AWS CDK synthesis process (implemented in TypeScript) must be invoked from within the Pulumi program. We are exploring ways to bring this support into other Pulumi (and CDK) languages as part of future updates to the library.

In the meantime, AWS CDK on Pulumi can be used within Component Packages implemented in TypeScript, and exposed to any Pulumi language (including newly supported Java and YAML.

Summary

Support for deploying AWS CDK constructs from within Pulumi programs opens up a wide range of new opportunities to interoperate between the AWS CDK and Pulumi ecosystems.For existing AWS CDK users, this provides new ways to deploy your CDK infrastructure and constructs. For existing Pulumi users, this opens up new higher-level libraries from the AWS CDK to use from within your Pulumi programs. We’re excited to be bringing these two communities closer together, and can’t wait to see what cloud builders can do with these two great cloud technologies together.

The AWS CDK on Pulumi project is open source at https://github.com/pulumi/pulumi-cdk and on NPM at https://www.npmjs.com/package/@pulumi/cdk. Get started today!

Pulumi Blog: Aws cdk

Announcing the 1.0 release of AWS CDK on Pulumi

Deploying CDK Constructs with Pulumi

Pulumi takes CDK apps to the next level

Expanded Features in pulumi-cdk 1.0

Using CDK Aspects

Example Output

CDK assets

Future direction

Summary

AWS CDK vs Pulumi: Why SST Chose Pulumi

In This Article:

The Beginnings of SST

CDK and CloudFormation Limitations

A Provider-agnostic Solution: Discovering Pulumi

Transitioning to Pulumi

The Benefits of Pulumi

Improved Visibility and Debugging

Extensibility and Customization

Multi-Cloud Capabilities

Simplified Mental Model

The Future of SST with Pulumi

Conclusion

Frequently Asked Questions

What is SST?

What is SST’s Ion?

Does SST use mostly Terraform or Pulumi?

How does SST make money?

Introducing AWS CDK on Pulumi

Deploying AWS CDK Constructs with Pulumi

Using AWS CDK Constructs Within Pulumi Programs

Building on AWS Native and the AWS Cloud Control API

Using High-Level “L3” Constructs

Future Directions

Summary