title: "Pulumi Crosswalk for AWS 1.0: AWSX, EKS, and AWS API Gateway"
# The date represents the post's publish date, and by default corresponds with
# the date this file was generated. Posts with future dates are visible in development,
# but excluded from production builds. Use the time and timezone-offset portions of
# of this value to schedule posts for publishing later.
date: 2022-11-28T12:00:00-07:00
# Use the meta_desc property to provide a brief summary (one or two sentences)
# of the content of the post, which is useful for targeting search results or social-media
# previews. This field is required or the build will fail the linter test.
meta_desc: Announcing the 1.0 release of Pulumi's Crosswalk for AWS libraries with support best practices components for ECS, EKS, API Gateway and more.
# The meta_image appears in social-media previews and on the blog home page.
# A placeholder image representing the recommended format, dimensions and aspect
# ratio has been provided for you.
meta_image: meta.png
# At least one author is required. The values in this list correspond with the `id`
# properties of the team member files at /data/team/team. Create a file for yourself
# if you don't already have one.
authors:
- luke-hoban
- daniel-bradley
# At least one tag is required. Lowercase, hyphen-delimited is recommended.
tags:
- features
- aws
# See the blogging docs at https://github.com/pulumi/pulumi-hugo/blob/master/BLOGGING.md.
# for additional details, and please remove these comments before submitting for review.
We introduced [Crosswalk for AWS](https://www.pulumi.com/docs/clouds/aws/guides/) three years ago as a library of components on top of the core AWS platform to make it easier to get from zero to production on AWS, easier to adopt AWS best practices by default, and easier to evolve your AWS infrastructure as your application needs mature. Since then, we’ve added many new capabilities, expanded the portfolio of libraries, and made these libraries [available to all Pulumi languages](https://www.pulumi.com/blog/crosswalk-for-aws-all-languages/). We’ve also seen thousands of Pulumi customers, including more than 25% of all Pulumi AWS users, adopting one or more of the Crosswalk for AWS components to aid in delivering their AWS-based applications and services.
Today, we’re excited to deliver the 1.0 releases of the three core libraries that make up Crosswalk for AWS: [AWSX 1.0](https://www.pulumi.com/registry/packages/awsx/), [EKS 1.0](https://www.pulumi.com/registry/packages/eks/) and [AWS API Gateway 1.0](https://www.pulumi.com/registry/packages/aws-apigateway/). These 1.0 releases offer a stable supported foundation, available in all Pulumi languages, for these rich infrastructure components.
Pulumi provides access to 100 providers (and counting!) for working with a wide variety of cloud and SaaS platforms. But since the very beginning of our work on Pulumi, [AWS](https://www.pulumi.com/registry/packages/aws/) has been the most used platform, both by the number of organizations using the provider, and by the average number of cloud resources managed per organization.
One of our guiding lights for Pulumi has always been to help organizations to scale up the complexity, capability, and richness of what they can build in the cloud, and in specific on the AWS platform. AWS offers an enormous number of powerful building block services, and organizations can stitch those building blocks together in countless ways to accomplish their needs. Pulumi brings a variety of software engineering tools to bear to help with this - rich programming languages, IDE productivity, testing, policy, and fast iteration. But none is more important than Pulumi’s focus on enabling the creation of [reusable infrastructure components](https://www.pulumi.com/docs/concepts/resources/components/) - higher level components that provide their own API interface built from the powerful building blocks of the underlying cloud resources.
The Crosswalk for AWS libraries offer components that help address many of the most common use cases we’ve seen AWS users need to tackle - configuring the many components of their VPC network setup, running containers on Amazon ECS and Fargate, configuring a fully featured and production ready Amazon EKS Cluster, and setting up the infrastructure and functions needed as part of a serverless architecture. All with just a few lines of code that offers AWS best practices out of the box, while offering the ability to scale up into the full features of the AWS platform.
## Crosswalk for AWS 1.0
The 1.0 releases of the [`awsx`](https://www.pulumi.com/registry/packages/awsx/), [`eks`](https://www.pulumi.com/registry/packages/eks/) and [`aws-apigateway`](https://www.pulumi.com/registry/packages/aws-apigateway/) packages offer a stable and supported foundation, available in all Pulumi languages, for these rich infrastructure components. They are available in the Pulumi Registry, and in all of the supported Pulumi package managers.
> **Note**: For TypeScript users, the `1.0.0` version of the `awsx` package contains some breaking changes from the `0.40.*` versions that were available only in TypeScript. The previously supported APIs are now available in the `@pulumi/awsx/classic` module inside the TypeScript `awsx` package. Users migrating from `0.40.*` to `1.0.*` can choose to either adapt their code and resources to the new APIs (which might require replacement or `import` of resources), or else to continue to use the `classic` submodule.
A few of the most significant components and libraries available in Crosswalk for AWS 1.0 are highlighted in the examples below, all available as part of Pulumi's [Architecture Templates](https://www.pulumi.com/templates/).
### Containers (ECS)
<imgalign="right"width="440"src="container.png">
Amazon Elastic Container Service (ECS) provides foundational services for running containers directly on the AWS platform, both against self-managed EC2 clusters, as well as in AWS Fargate’s managed serverless container platform.
The AWSX 1.0 package provides components that make it incredibly easy to take a container, or even just a folder with a `Dockerfile`, and run it in a production-ready environment in AWS. And unlike some bespoke solutions for container deployment, with AWSX, configuring networking, load-balancing, secrets, managed databases, or anything else needed is just a few lines of code away.
Our recently released [Container Service on AWS](https://www.pulumi.com/templates/container-service/aws/) template provides a great starting point for leveraging the AWSX 1.0 support for ECS, Fargate, ECR and ALB.
Amazon Elastic Kubernetes Service (EKS) offers a managed Kubernetes service for standing up a best practices Kubernetes cluster within AWS.
The EKS 1.0 package offers support for configuring the many building blocks needed to configure a complete EKS cluster, across both AWS resources as well as in-cluster Kubernetes resources using Pulumi's native `kubernetes` provider. With `eks.Cluster`, `eks.NodeGroup`, `eks.NodeGroupV2` and `eks.ManagedNodeGroup` this package makes it easy to configure a cluster using any of the compute options available in AWS in just a few lines of code.
Our recently released [Kubernetes Cluster on AWS](https://www.pulumi.com/templates/kubernetes/aws/) template provides a great starting point for leveraging the `eks` 1.0 support for EKS, taking advantage of default support for private networking and EC2-based compute.
// Change configuration values above to change any of the following settings
InstanceType: pulumi.String(eksNodeInstanceType),
DesiredCapacity: pulumi.Int(desiredClusterSize),
MinSize: pulumi.Int(minClusterSize),
MaxSize: pulumi.Int(maxClusterSize),
// Do not give the worker nodes a public IP address
NodeAssociatePublicIpAddress: pulumi.Bool(false),
// Uncomment the next two lines for a private cluster (VPN access required)
// EndpointPrivateAccess: pulumi.Bool(true),
// EndpointPublicAccess: pulumi.Bool(false),
})
if err != nil {
return err
}
// Export some values in case they are needed elsewhere
ctx.Export("kubeconfig", eksCluster.Kubeconfig)
ctx.Export("vpcId", eksVpc.VpcId)
return nil
})
}
```
{{% /choosable %}}
{{% choosable language csharp %}}
```csharp
using Pulumi;
using Awsx = Pulumi.Awsx;
using Eks = Pulumi.Eks;
using System.Collections.Generic;
return await Deployment.RunAsync(() =>
{
// Grab some values from the Pulumi configuration (or use default values)
var config = new Config();
var minClusterSize = config.GetInt32("minClusterSize") ?? 3;
var maxClusterSize = config.GetInt32("maxClusterSize") ?? 6;
var desiredClusterSize = config.GetInt32("desiredClusterSize") ?? 3;
var eksNodeInstanceType = config.Get("eksNodeInstanceType") ?? "t2.medium";
var vpcNetworkCidr = config.Get("vpcNetworkCidr") ?? "10.0.0.0/16";
// Create a new VPC
var eksVpc = new Awsx.Ec2.Vpc("eks-vpc", new()
{
EnableDnsHostnames = true,
CidrBlock = vpcNetworkCidr,
});
// Create the EKS cluster
var eksCluster = new Eks.Cluster("eks-cluster", new()
{
// Put the cluster in the new VPC created earlier
VpcId = eksVpc.VpcId,
// Public subnets will be used for load balancers
PublicSubnetIds = eksVpc.PublicSubnetIds,
// Private subnets will be used for cluster nodes
PrivateSubnetIds = eksVpc.PrivateSubnetIds,
// Change configuration values to change any of the following settings
InstanceType = eksNodeInstanceType,
DesiredCapacity = desiredClusterSize,
MinSize = minClusterSize,
MaxSize = maxClusterSize,
// Do not give the worker nodes public IP addresses
NodeAssociatePublicIpAddress = false,
// Uncomment the next two lines for a private cluster (VPN access required)
// EndpointPrivateAccess = true,
// EndpointPublicAccess = false,
});
// Export some values for use elsewhere
return new Dictionary<string,object?>
{
["kubeconfig"] = eksCluster.Kubeconfig,
["vpcId"] = eksVpc.VpcId,
};
});
```
{{% /choosable %}}
{{% choosable language yaml %}}
```yaml
name: aws-kubernetes-cluster
description: Kubernetes Cluster on AWS
runtime: yaml
config:
minClusterSize:
default: 3
maxClusterSize:
default: 6
desiredClusterSize:
default: 3
eksNodeInstanceType:
default: t2.medium
vpcNetworkCidr:
default: 10.0.0.0/16
resources:
# Create a VPC for the EKS cluster
eks-vpc:
type: awsx:ec2:Vpc
properties:
enableDnsHostnames: true
cidrBlock: ${vpcNetworkCidr}
# Create the EKS cluster
eks-cluster:
type: eks:Cluster
properties:
# Put the cluster in the new VPC created earlier
vpcId: ${eks-vpc.vpcId}
# Public subnets will be used for load balancers
publicSubnetIds: ${eks-vpc.publicSubnetIds}
# Private subnets will be used for cluster nodes
privateSubnetIds: ${eks-vpc.privateSubnetIds}
# Change configuration section above to change any of the following settings
instanceType: ${eksNodeInstanceType}
desiredCapacity: ${desiredClusterSize}
minSize: ${minClusterSize}
maxSize: ${maxClusterSize}
# Do not give the worker nodes public IP addresses
nodeAssociatePublicIpAddress: false
# Uncomment next two lines for private cluster access (VPN access required)
# endpointPrivateAccess: true
# endpointPublicAccess: false
outputs:
# Output the Kubeconfig for the cluster
kubeconfig: ${eks-cluster.kubeconfig}
vpcId: ${eks-vpc.vpcId}
```
{{% /choosable %}}
{{% /chooser %}}
### Serverless (Lambda, API Gateway)
<imgalign="right"width="440"src="serverless.png">
AWS Lambda and the serverless architectures it enables provide native support for event based compute triggered off of a wide variety of events from within the AWS platform. Coupled with services like AWS API Gateway, this offers simple ways to serve HTTP-based APIs and much, much more.
Pulumi's built in support for AWS Lambda functions and the new `aws-apigateway` 1.0 package make it simple to compose these services to build serverless applications and services on AWS in just a few lines of code.
Our recently released [AWS Serverles Application](https://www.pulumi.com/templates/serverless-application/aws/) template provides a great starting point for leveraging the `aws-apigateway` 1.0 support for creating a complete API Gateway-based serverless application, serving both static content from Amazon S3 as well as dynamic backend logic from AWS Lambda.
Before version 1, AWSx only supported components in TypeScript. All the existing components from the 0.x releases are now available in the `classic` namespace. The `classic` namespace will remain until the next major version release but will only receive updates for critical security fixes.
If you're currently using v0.x and want to upgrade to v1.x you can:
1. Change references from `@pulumi/awsx` to `@pulumi/awsx/classic` to maintain existing behaviour.
2. Refactor to replace the classic components with the new top-level components. This may require additional code changes and resource re-creation.