Skip to content
Related Articles

Related Articles

Improve Article

Amazon Web Services – Introduction to Solutions Constructs

  • Last Updated : 24 May, 2021

This is an introductory article on AWS Solutions Constructs. If you’re not familiar with solution constructs, in short, they’re a set of reusable architecture components that allow you to create better infrastructure as code stacks and create them faster. 

Let’s first talk about infrastructure as code. At AWS that starts with AWS cloud formation the Infrastructure as Code(IaS) service. Cloud formation allows you to define complete cloud architectures using declarative YAML or JSON templates. These templates are amazingly powerful mechanisms to create infrastructure as code. Here’s a snippet of JSON that defines an SQS Queue and cloud formation. 

"gfg_queue 529S8454": {
"Type": "AWS:: SQS::Queue",
"Properties": {
"MaximumMessageSize": 1130,
"QueueName": "demo-queue"
}
}

Now, these templates can grow very long and very complex plus by nature they’re static so to vary the infrastructure based on deployment conditions is a challenge. Fortunately, there’s a better way to create these cloud formation templates than your text editor. The AWS Cloud Development Kit or AWS CDK provides a layer of abstraction over confirmation templates that allows you to define your infrastructure using conventional programming languages rather than declarative markup. This makes defining cloud formation stacks easier as well as giving you more power. In CDK, defining a new queue looks like this:

new sqs.Queue (this, 'gfg-queue', { 
    queueName: 'gfg-queue', 
    maxMessageSizeBytes: 1130,
});

You simply instantiate a new queue object but since it’s a programming language you can create things more dynamically. For instance, if you only want to create a resource under certain conditions you can wrap it in a conditional as shown below:



if (environment == 'PROD') {
    new sqs.Queue (this, 'gfg-queue',{
     queueName: 'demo-queue',
     maxMessageSizeBytes: 1130,
});
}

 If you want multiple resources based upon runtime values you can wrap the instantiation in a loop as shown below:

inputs.forEach( input => {

    new sqs.Queue (this, input-${input.id)', { 
     queueName: input-${input.id}', 
     maxMessageSizeBytes: 1130,
});
});

This example is written in typescript, but you can also use the CDK with python, .net, and java. At the heart of all this is still cloud formation, but this abstraction over the raw cloud formation alleviates the need for authoring YAML or JSON and makes your cloud formation stacks more dynamic.

AWS solutions constructs are implementations of common architectural patterns that you can plug into your CDK stacks either on their own or connected to other solutions constructs. They are all built on top of the CDK and therefore on top of cloud formation underneath that. They not only save you time and code, but they deploy the pattern using best practices and include architectural elements you may neglect if you were building your stack from scratch.

Let’s look at AWS-SQS lambda, a construct that deploys an SQS-Queue along with a lambda function that’s invoked whenever a message is stored in the queue. Here’s how you would deploy that in your CDK program just by instantiating an SQS to lambda object:

new SqsToLambda (this, 'SqsToLambdaPattern',{
 lambdaFunctionProps: {
runtime: lambda.Runtime. NODEJS_10_X,
handler: 'function.handler',
code: lambda.Code.fromAsset (`lambda)
},

queue Props: {
maxMessageSizeBytes: 1130,
queueName: 'gfg-queue'
});

The construct deploys a queue and a lambda function, but the interaction of these two services actually requires several other resources to be both functional and secure such as:

List of Resources:

  1. AWS: : IAM: : Role
  2. AWS: :IAM : : Policy
  3. AWS: :Lambda:: Function
  4. AWS: :Lambda: : EventSourceMapping
  5. AWS: :SQS: : Queue
  6. AWS: :SQS : : QueuePolicy
  7. AWS: :SQS: : Queue (Dead Letter)

The construct actually launches 7 services for you automatically. It provides better architectures in addition to faster architectures that’s because solutions constructs all default to recommended or best practices. Some areas where you’ll see this are:

  • Your resources which are all encrypted by default
  • IAM roles and policies follow the principle of the least privilege restricting allowed actions and targeting resources
  • Error handling architecture is set up architecture such as dead letter queues

There are currently over 35 solution constructs published in the library with more on the way. Here’s a simple data ingestion system where external actors store data in an SQS-Queue, the queue triggers a lambda function to process the data and save the process data to a Dynamodb table. To launch this using solutions constructs is nearly trivial. You can create this architecture using two solutions constructs AWS SQS lambda and AWS lambda Dynamodb.

These constructs can be connected through the lambda function to create the desired architecture. 

My Personal Notes arrow_drop_up
Recommended Articles
Page :