DEV Community: JNN5

AWS CDK tips and tricks for developers

JNN5 — Thu, 13 Feb 2025 03:01:20 +0000

The AWS CDK is for most of the people I interact with the first-time developers who get to write Infrastructure as Code in a proper programming language (sorry HCL, we were never friends).

This sounds like a game changer but when you look at a lot of the examples it doesn’t really feel like programming. Instantiating classes with the same attributes you used in YAML or JSON doesn’t feel like a big gain.

However, when you give it a shot there are some pretty neat things you can do.

What is the AWS CDK

The AWS CDK is a library for multiple languages and a cli to provision infrastructure on AWS and more.

You use one of the major programming languages like TypeScript/Python/Java/C# etc. to define your infrastructure as instantiated classes. The CLI can turn these objects of the respective programming languages and turn them into CloudFormation templates and deploy them via the CloudFormation service.

I won’t go into more detail here than this little tldr; use your favorite search engine to find out more if you feel like it.

Tips and tricks

When you use the CDK out of the box, I don’t find it fun to use. Most classes have lots of parameters and some constructs depend on other constructs that then have more parameters and there is no logic flow.

The classes are modelled after the AWS services rather than the way someone might approach building an app.

It’s a good thing you can use proper programming languages to do something about it.

Trick 1: Build your own constructs with sensible defaults
Are you using lambda functions in Python with tracing? Build a PythonFunction that enables tracing with a fixed layer for lambda Powertools.

Don’t want to forget to encrypt a S3 bucket and make it private? Build an EncryptedBucket construct.

For any resource that is used multiple times, it’s probably a good idea to build your own construct and set some defaults.

*Trick 2: Co-locate application and infrastructure code
*
You could technically put application and infrastructure code in the same file but that might not be a very good idea.

What I like to do is e.g. co-locate my lambda function code with the infrastructure code for that lambda in different files but in the same folder. And by that I mean the function definition and all other components exclusive to that feature like e.g. a path in the API gateway and the DynamoDB table the lambda writes to.

This way, if I’m working on a feature, I have everything that makes up the feature in one place which makes updates much easier. This leads to the nice property that my CDK stack definition is entirely made up of a collection of features that form the stack.

*Tip 3: Abstract your constructs the way you would think about your architecture
*
I think this one needs a little more explaining.

What I mean is that the way the AWS CDK constructs are built is by following the topology of AWS services and service boundaries. This might not be how you would want to design systems.

E.g. When I write a function for a feature, I would think about the architecture from the viewpoint of the function.

I would think this way. “This function is being triggered from a POST request from an API. It also writes to this database.”

The AWS constructs make you declare it as follows. “This API has this path with this method and this integration to this lambda function. This table grants write access to this function.”

I’ll write it down in pseudo-code (assuming you’re using Trick 1 for both my and AWS’ way)

`# my way
my_api = RestAPI(…)
my_table = EncryptedTable(…)
my_function = PythonFunction(…)

my_function.is_triggered_by_api(my_api, “/my_feature”, “POST”)
my_function.writes_to(my_table)`

`# AWS CDK way
my_api = RestAPI(…)
my_table = EncryptedTable(…)
my_function = PythonFunction(…)

my_api.add_method(“/my_feature”, “POST”, my_function)
my_table.grants_readwrite(my_function)`

If you think in integration patterns or even in your domain language, you can communicate that via your constructs. The code above is just a simple example.

Trick 4: don’t duplicate schemas
Sometimes the boundaries in what is application code and infrastructure code are blurry. That’s not necessarily a problem as it allows developers to get things done in multiple ways. However, it can be a problem when both sides have definitions that have to match.

A good example would be DynamoDB. Most developers would likely use an abstraction layer in their application code to enforce a schema to be able to work with types. But you might not want all the config to be purely in your application code (like streams, backups, billing, etc.).

What you can do is take your application code schema and feed it into your infrastructure as code. But please note, that this might require reflection or some other technique to access the metadata of a class. Here is some pseudo code to elaborate what I mean

`# Application code ORM DynamoDB table definition

@Table
class Flight
fight_id: str
takeoff: daytime
origin: str
destination: str
takeoff_index: SecondaryIndex


# Infrastructure code (in a different file)
flight_table = EncryptedTable.from_orm_class(Flight, Mode.OnDemand)`

Final Tip: CDK synth and is your friend
If you’re using IaC, chances are you’re deploying via some sort of pipeline. And likely deployment is one of the last steps. This means that anytime you get something wrong in CDK your feedback loop is slow. To speed things up, you can first check that your CDK code can be synthesized to CloudFormation by running CDK synth (either via your test runner or the CLI).

I hope my tips and tricks have helped you in one way or another. If you have any other ones you’d like to share, I’d be grateful for any comments!

Photo by John Fornander on Unsplash

[Boost]

JNN5 — Fri, 07 Feb 2025 12:18:54 +0000

This New AWS Serverless Stack could be a Game-Changer

JNN5 ・ Jan 24

#aws #docker #development #serverless

This New AWS Serverless Stack could be a Game-Changer

JNN5 — Fri, 24 Jan 2025 15:30:08 +0000

There is a new AWS serverless stack on the rise that you should know about!

AWS has been increasing its serverless service offerings and has also begun providing serverless options for existing services.

Companies and individuals who are concerned about vendor lock-in have historically tried to avoid using serverless offerings from cloud providers to avoid being dependent on their unique offerings.

Historically the standard AWS serverless tech stack consisted of services that are difficult to reproduce with OpenSource technology like:

Amazon API Gateway
AWS Lambda
Amazon DynamoDB
AWS Step Functions
Amazon S3
etc.

However, there is a new stack that doesn’t have this problem. This new stack can simply be run anywhere and with various OpenSource technologies.

The New Stack

How would a technology stack have to look like to be deployed almost anywhere? First, it would have to be open-source. Second, it would have to be considered an industry standard to be viable for most businesses. However, whether it’s processor types, hypervisors, operating systems, programming languages, frameworks, and so on, our industry has loads of varying opinions about most things and proprietary technology is a very common business model. However, there are a few that are very, wide-spread.

Docker for running applications
SQL for databases

Yes, NoSQL is on the rise, but if you look at most of the application full-stack frameworks, across languages, most of them either support or even only support SQL databases:

Spring/Spring Boot in the Java world
.Net in C#
Django in Python
Rails in Ruby
Laravel for PHP
NestJS for JavaScript (ignoring NextJS because it doesn’t have built-in database integration)

Here is what changed
With AWS Lambda as the compute layer and DynamoDB as the database. Developers had a choice to make.

Lambda was often not a great fit for existing frameworks and you typically need an additional dependency to interact with DynamoDB.

So, either bend the framework to work with Lambda or stop using a framework and completely adapt to the AWS stack.

Sticking to the framework could often lead to longer processing times and thereby higher costs.

This has changed! Last year AWS released a very interesting new service called Amazon App Runner.

Amazon App Runner

This service is interesting because it follows a different paradigm. With the API Gateway and Lambda stack, the web and application server were moved into the cloud provider layer and the configuration moved out of the application code.

All of the frameworks listed above bring application servers and expose endpoints, which were already covered by API Gateway.

With App Runner, the application server and API layer are now the responsibility of the developer but App Runner covers routing, scaling, and networking.

This makes frameworks first class citizens, because providing an application server that can process requests is exactly what a framework is for.

Now with frameworks back in the picture, all we need is a real serverless SQL database.

Amazon Aurora DSQL

Currently, DSQL is still in beta, but in my opinion, it’s a game changer. Before DSQL if you wanted to run a SQL database in AWS, you had to also run a VPC, Subnets, Route Tables, Internet Gateway, Security Groups, NACLs, NAT Gateways, etc. Now while one could argue that you can set these up once via Infrastructure as Code and be done with it, I dislike this. The reason is that if I have to set up the network, then I’m suddenly responsible for network-level security.

Meaning if, even by accident I change some routing or security group settings and expose my database. It's on me and suddenly I have to consider whether a team of application developers will be willing and skilled enough to run this themselves.

DSQL is a truly serverless offering (unlike previous Aurora offerings) where AWS provides an endpoint for me to access the database and handles all other network and system-level security for me. Meaning that I don't have to create a VPC etc. to provision DSQL.

The New Mental Model

Just judging by the icons this new stack doesn’t seem all that different I admit.

1. You change your infra less
You have to write the IaC code for App Runner and DSQL once at the beginning of the project. When you need a new endpoint, you don’t have to touch the IaC. When you need a new table, you don’t have to touch the IaC. When you want to change your database schema, you don’t have to touch IaC. You only have to care about your infrastructure when you have to make changes to your core platform. This is great because it allows you to stay in your application context more and you don’t lose time by switching context.

2. You can test locally more easily
Your local testing setup is much simpler. Start Postgres and you’re done. Well almost, your connection locally is set up differently than in the cloud and you manage secrets differently, but calling a running endpoint that talks to a database doesn’t require complex config anymore.

3. Faster onboarding
Developers don’t need to understand much about AWS to be productive. 100 lines of IaC is digestible. Especially if you don’t need to change them that often. Several hundred lines of IaC can be daunting.

Trade-offs

Don’t trust anyone that doesn’t tell you about the trade-offs.

1. Container image hardening
While it is possible to let AWS provide the image, I predict that most users will bring their own docker image and thereby be responsible for the security.

2. API Gateway features not available
Rate limiting, API keys with usage plans, and Cognito Authorizer are probably my top 3 features that either the framework would have to provide or the developer would have to implement them.

3. Cost currently unclear
This is probably the biggest blocker at the moment. DSQL is in public beta but currently there is no information on pricing and how AWS will charge for DSQL. This could make this stack not viable for a lot of use cases but we will just have to wait and see.

I’m excited about this new serverless stack and the new mental model it comes with.

I feel like it would be a great fit for developers who are annoyed by Kubernetes' complexity or the amount of IaC they have to manage.

Finally, for teams trying to move away from microservices to moduliths (or modern monoliths), this is the most viable stack if you want to stay truly serverless.

The beautiful Cover Photo was taken by Kari Sheas and published on Unsplash