In recent years, the adoption of containers has revolutionized the way applications are developed, deployed, and managed. This rise in popularity is attributed to significant advantages in terms of portability and isolation. Understanding the available options is crucial for making informed decisions aligned with specific workload requirements. While Kubernetes is a well-known solution for managing container workloads, it is not the only option. In this post, I will introduce other services that can be beneficial in choosing the right solution.

While Kubernetes is pretty robust and popular, it’s crucial to understand that it’s not the only option for managing container workloads. AWS provides a range of alternatives that can support your container workloads, potentially leading to optimized costs and efficiency. These alternatives include services like AWS Elastic Container Service (ECS), which offers easy integration with AWS infrastructure, and AWS Fargate, which allows for serverless container deployment. Additionally, AWS Elastic Kubernetes Service (EKS) can be an option for those who prefer Kubernetes but want deeper integration with AWS services. Each of these services offers unique features and benefits, making it important to evaluate them based on your specific requirements and objectives.

Main Platforms

EKS
EKS is AWS’s managed Kubernetes service, perfect for those who require the full functionality of Kubernetes without the overhead of managing the control plane. It’s particularly suited for environments with complex, multi-service architectures, offering the scalability and flexibility that Kubernetes is known for.

ECS
ECS is a fully managed container management service, ideal for users seeking a straightforward solution for running Docker containers. It excels in environments that value simplicity and seamless integration with AWS services, such as EC2 and Fargate. ECS offers a balance of control and ease of use, making it suitable for a wide range of applications, from simple web apps to more sophisticated microservices architectures. It is particularly appealing for those who prefer a less complex alternative to Kubernetes, without compromising on the essential features needed for effective container management.

AppRunner
AWS AppRunner is the simplest solution for running web applications and APIs, designed for users who prioritize ease of use and quick deployment over extensive customization. It’s a fully managed service, eliminating the need for infrastructure management, and is optimal for straightforward applications where default configurations suffice. AppRunner automatically scales resources to match demand, ensuring efficient operation with minimal manual intervention. This service is particularly suited for developers and businesses looking to rapidly deploy their applications without delving into the complexities of container orchestration or server management. While it offers less customization than services like ECS or EKS, AppRunner is an excellent choice for projects where speed and simplicity are the main requirements.

Computing Options

AWS Fargate:

Fargate is a serverless compute engine offered by AWS, specifically designed for running containers. It abstracts the underlying infrastructure, removing the need to provision and manage servers or clusters. When you use Fargate with ECS (Elastic Container Service) or EKS (Elastic Kubernetes Service), you simply specify the CPU and memory requirements for your containers, and Fargate handles the rest. It automatically allocates the compute resources, runs the containers, and scales them as needed, making it an ideal choice for users who prefer a hands-off approach to infrastructure management.

Amazon EC2:
Amazon EC2 (Elastic Compute Cloud) is a service that provides resizable compute capacity in the cloud, using virtual machines known as instances. When running containers on EC2, you have full control over these instances, meaning you can choose the type of instance, configure the operating system, and have complete control over the network and security settings. This level of control is particularly beneficial for applications that require specific configurations or optimizations. Using EC2 with ECS or EKS allows you to manage the underlying infrastructure for your container workloads, offering flexibility and control for more complex deployment scenarios.

Tooling
AWS Copilot: Designed for ECS: AWS Copilot is specifically built for Amazon ECS. It provides a command-line interface (CLI) that simplifies the process of deploying and managing containerized applications on ECS.
Copilot assists in setting up an entire ECS architecture, including the creation of ECS services, task definitions, and cluster configurations. It also aids in setting up CI/CD pipelines, load balancers, and logging.
It is designed to be user-friendly, making it easier for developers to start with ECS without needing to deeply understand all the underlying details of AWS services.

Kubectl: Kubectl is the command-line tool for Kubernetes and is used with AWS EKS. It allows users to deploy and manage applications on Kubernetes, control cluster resources, and view logs.
Kubernetes Operations: With Kubectl, users can perform a wide range of Kubernetes operations such as deploying applications, inspecting and managing cluster resources, and viewing logs and statuses of resources in the cluster.

For AWS AppRunner, the tooling is more integrated and abstracted, as AppRunner is a fully managed service with a focus on simplicity. Users typically interact with AppRunner through the AWS Management Console or AWS CLI. The service automates deployments and infrastructure management, so there’s less need for specialized tooling like Copilot or Kubectl.

So which one to use?

Choose EKS for:

• Complex, large-scale applications.
• Projects needing Kubernetes API support.
• Migrating to a Kubernetes environment.
• Cost-effective container deployment.
• Deploying across multiple infrastructures.
• Utilizing Kubernetes’ flexibility.

Choose ECS for:

• Simple, easy application management.
• Situations where advanced EKS features aren’t needed.
• Exclusive AWS focus with limited Kubernetes know-how.
• Deep AWS service integration.
• Scenarios with limited resources for Kubernetes migration.
• Quick, streamlined container management.

For Computing Options, Choose:

Fargate for:

• Serverless container deployment.
• Automated scaling and management.
• Focusing on applications over infrastructure.
• Variable workloads with a pay-as-you-go model.
• Strong application isolation.

EC2 for:

• Full control over the environment.
• Customizable compute needs.
• Long-running, steady workloads.
• Detailed monitoring and configuration.
• Stable workloads with cost-effectiveness.

For Tooling, Choose:

Copilot for:

• Easy-to-use CLI for ECS and Fargate.
• Streamlining application workflow.
• Seamless AWS service integration.
• Automated infrastructure management.
• Simplified Docker management.

Kubectl for:

• Managing Kubernetes clusters.
• Detailed control over Kubernetes resources.
• Versatile cluster operations.
• Advanced Kubernetes management.
• Access to a wide range of Kubernetes tools and plugins.

There you have it. There are many ‘whens’ and ‘ifs’. Generally, if you don’t have existing Kubernetes workloads and your primary goal is to run container-based services on AWS, I would recommend ECS. ECS also supports external instances on-premises through ECS Anywhere. As for computing options, if you prefer less overhead, then Fargate is a good choice. Regarding tooling, Copilot would be your best bet with these selections.

Hosting Container Workloads on AWS: Here Are Your Options was originally published in TysonWorks on Medium, where people are continuing the conversation by highlighting and responding to this story.

The appeal of adopting a multi-cloud strategy in today’s dynamic and ever-evolving cloud landscape is quite significant. This strategic approach entails the deployment of various cloud computing services within a single, diverse architecture, aiming to provide enhanced reliability and flexibility, while also potentially reducing costs. Despite these apparent advantages, the practical execution of a multi-cloud strategy can be far more intricate and may not always yield the anticipated benefits. In this discussion, we will delve deeper into the reasons why a multi-cloud strategy, despite its initial attractiveness, might not always be the most advantageous path for a multitude of businesses

The Hidden Costs of Data Egress

One of the most significant, yet frequently underestimated, concerns in a multi-cloud setup is the cost associated with data egress. When data is transferred extensively between different cloud environments, the fees can accumulate swiftly. These costs are often overlooked during the planning phase but can result in a substantial financial burden as the data scales. For businesses, particularly those handling large datasets, this can translate into unpredictably high operational costs, negating one of the primary advantages of cloud computing — cost efficiency.

The Widening Skill Gap

Adopting a multi-cloud strategy introduces a notable challenge: the widening skill gap. Each cloud platform, such as AWS, Azure, or Google Cloud, comes with its own unique set of tools and services, requiring specific expertise. This diversity necessitates a broader skill set from the IT team. For businesses, this means investing in extensive training, or hiring new personnel with the requisite skills, which can be a costly and time-consuming endeavor. Furthermore, the diversity in skill requirements can slow down development and deployment processes, affecting the overall agility and responsiveness of the organization.

Amplified Security Risks

While multi-cloud environments can offer redundancy and thus potentially increase resilience to localized failures, they also amplify security risks. Each cloud provider implements its own security protocols and compliances. Ensuring a consistent and robust security posture across multiple platforms is a complex task, often leading to gaps in the security framework. These gaps can make the infrastructure more vulnerable to cyber threats, requiring additional resources to monitor and secure multiple environments effectively.

The Comprehensive Nature of Single Cloud Providers

A primary argument for adopting a multi-cloud strategy is to leverage the best-of-breed services from various providers. However, this perspective might not be as relevant today as it once was. Major cloud providers like AWS offer a comprehensive suite of services that cater to a wide array of business needs. These services are continually evolving, with providers regularly adding new features and capabilities. This ongoing development often diminishes the need to mix and match services from multiple clouds, as a single provider frequently offers a holistic solution.

Conclusion

While the concept of a multi-cloud approach is attractive for its promise of flexibility, redundancy, and choice, the reality involves considerable challenges in terms of costs, skills, and security. Moreover, the evolving nature of major cloud providers, like AWS, often makes them a one-stop solution for most business requirements. Therefore, before committing to a multi-cloud strategy, it is crucial for businesses, especially those looking to optimize operational efficiency and cost, to thoroughly evaluate these factors. As a cloud consultant, my recommendation is to assess your specific business needs meticulously and weigh the pros and cons of a multi-cloud approach against the streamlined, comprehensive solutions offered by single cloud providers.

Why Multi-Cloud is Not a Good Idea? was originally published in TysonWorks on Medium, where people are continuing the conversation by highlighting and responding to this story.

AWS has recently announced AWS GuardDuty support for AWS Lambda Protection. This tool identifies potential security threats when an AWS Lambda function gets invoked in your AWS environment. In this tutorial, I will guide you through the steps to enable and how to remedy potential issues.

Lambda Protection provides a crucial security layer by monitoring Lambda network activity logs, starting with VPC Flow Logs from all Lambda functions for your account. This includes logs that don’t use VPC networking and logs generated when the Lambda function gets invoked.

When GuardDuty identifies suspicious network traffic, potentially indicating a malicious piece of code within your Lambda function, a finding is generated. This allows you to be proactive in safeguarding your environment.

Getting Started
By default, an existing GuardDuty account can enable Lambda Protection with a 30 day trial period. For a new GuardDuty account, Lambda Protection is already enabled and included in the 30 day trial period.

Let’s get started with enabling Lambda Protection:

Lambda Network Activity Monitoring
GuardDuty monitors network activity logs generated by invoking the Lambda functions. This includes Amazon VPC flow logs from all Lambda functions for your account, even those logs that don’t use VPC networking.

Cost Optimization
GuardDuty only charges for the amount of Lambda network activity logs data processed (in GB) to generate a finding. This approach optimizes cost by applying smart filters and analyzing a subset of Lambda network activity logs relevant to threat detection.

Understanding Log Management
GuardDuty doesn’t manage your Lambda network activity logs (including VPC and non-VPC flow logs) or make them accessible in your account. Instead, it focuses on analyzing logs to identify potential threats.

What happens if your Lambda Functions are compromised?

In the event that GuardDuty generates a Lambda Protection finding and the activity is unexpected, indicating your Lambda function may be compromised, it is essential to take immediate steps to remediate the issue. Here are the three steps you can follow.

Step 1: Identify the Affected Lambda Function Version
A GuardDuty finding for Lambda Protection provides the name, Amazon Resource Name (ARN), function version, and revision ID associated with the Lambda function listed in the finding details. Save these details as they will be needed in the subsequent steps.

Step 2: Identify the Source of the Suspicious Activity
The next step is to identify the source of the suspicious activity:

• Review the code: Examine the code associated with the Lambda function version involved in the finding. Look out for any unusual or unexpected code blocks.
• Review the imported libraries and layers: Inspect the libraries and layers of the Lambda function version involved in the finding. Ensure these libraries and layers are trusted and required for your function.
• Use Amazon Inspector: If you have enabled Scanning AWS Lambda functions with Amazon Inspector, review the Amazon Inspector findings associated with the Lambda function involved in the finding.
• Review AWS CloudTrail logs: AWS CloudTrail logs will help identify the principal that caused the function update. Ensure that the activity was authorized or expected.

Step 3: Remediate the Impacted Lambda Function
After identifying the source of the suspicious activity, the next step is to remediate the compromised Lambda function:

• Disable the execution triggers: Temporarily disable the execution triggers of the Lambda function involved in the finding to prevent any further potential damage. For more information, see DeleteFunctionEventInvokeConfig.
• Review and update the Lambda code: Go through the Lambda code and update the libraries imports and Lambda function layers to remove the potentially suspicious libraries and layers.
• Mitigate Amazon Inspector findings: If Amazon Inspector findings are associated with the compromised Lambda function, take appropriate steps to mitigate them.

GuardDuty’s Lambda Protection feature helps you tackle security threats to your AWS Lambda functions proactively. It’s a new tool in your DevSecOps toolkit that alerts you about possible threats.

Protect Your Lambda Functions with AWS GuardDuty was originally published in TysonWorks on Medium, where people are continuing the conversation by highlighting and responding to this story.

AWS Cloud Development Kit (CDK) is a powerful Infrastructure as Code (IaC) tool, it’s used by AWS internally and many people are favoring CDK’s simple and powerful capabilities. CDK has many options, as a someone who worked many years in TypeScript/JavaScript world, it feels natural to me.

In this tutorial I will show you a very simple solution for managing cross-stack references. If you are familiar with CloudFormation, here is how you would be solving that problem

Use the Export output field to flag the value of a resource output for export. Then, use the Fn::ImportValue intrinsic function to import the value.

Define the references as Outputs.

…..
 "Outputs" : {
 "VPCId" : {
 "Description" : "VPC ID",
 "Value" : { "Ref" : "VPC" },
 "Export" : { "Name" : {"Fn::Sub": "${AWS::StackName}-VPCID" }}
 },
 "PublicSubnet" : {
 "Description" : "The subnet ID to use for public web servers",
 "Value" : { "Ref" : "PublicSubnet" },
 "Export" : { "Name" : {"Fn::Sub": "${AWS::StackName}-SubnetID" }}
 },
 "WebServerSecurityGroup" : {
 "Description" : "The security group ID to use for public web servers",
 "Value" : { "Fn::GetAtt" : ["WebServerSecurityGroup", "GroupId"] },
 "Export" : { "Name" : {"Fn::Sub": "${AWS::StackName}-SecurityGroupID" }}
 }
 }

Then later referencing from another stack.

….
 "Properties": {
 "InstanceType" : "t2.micro",
 "ImageId": { "Fn::FindInMap": [ "AWSRegionArch2AMI", { "Ref": "AWS::Region" } , "HVM64" ] },
 "NetworkInterfaces" : [{
 "GroupSet" : [{ "Fn::ImportValue" : {"Fn::Sub": "${NetworkStackName}-SecurityGroupID" } }],
 "AssociatePublicIpAddress" : "true",
 "DeviceIndex" : "0",
 "DeleteOnTermination" : "true",
 "SubnetId" : { "Fn::ImportValue" : {"Fn::Sub": "${NetworkStackName}-SubnetID" } }
 }],

Let’s try to replicate the same thing with two simple CDK stacks. In the first stack, we will be creating a DynamoDB table. In the second Stack, we will create a Lambda function and pass a reference to the DynamoDB table referenced in the first Stack.

Here is the DynamoDB Stack.

class DynamoStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const dynamoTable = new dynamodb.Table(this, "dynamo-table", {
      partitionKey: {
        name: "id",
        type: dynamodb.AttributeType.STRING
      },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST
    });

  }
}

Just one DynamoDB table, Pay per Request billing option. Let’s define the Lambda Stack.

interface LambdaStackProps extends cdk.StackProps  {
  DYNAMO_TABLE_NAME: string;
}

class LambdaStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: LambdaStackProps) {
    super(scope, id, props);

    const LambdaFunction = new lambda.Function(this, "lambda-function", {
      code: lambda.InlineCode.fromInline(`exports.handler = function(event, ctx, cb) {
          console.log(process.env.DYNAMO_TABLE_NAME);
         return cb(null, 'hello world'); 
        }`),
      handler: "index.handler",
      runtime: lambda.Runtime.NODEJS_18_X,
      environment: {
        DYNAMO_TABLE_NAME: props.DYNAMO_TABLE_NAME
      }
    });

  }
}

Notice that we are using props.DYNAMO_TABLE_NAME variable. We need a way to pass this information.

const app = new cdk.App();

const dynamoStack = new DynamoStack(app, "DynamoStack", {
  env: {
    region: process.env.AWS_REGION,
    account: process.env.AWS_ACCOUNT_ID
  }
});

const lambdaStack = new LambdaStack(app, "LambdaStack", {
  env: {
    region: process.env.AWS_REGION,
    account: process.env.AWS_ACCOUNT_ID
  },
  DYNAMO_TABLE_NAME: dynamoStack.stackName
})

Very simple, yet effective. Now you might ask why we can’t have both resources in the same Stack. The answer is yes, you can. But when your Stacks get bigger, it’s a good idea to separate Stacks into Logical Units. For example, your database resources can be under Data Stack, your Lambda functions might be in Lambda Stack, whereas your Kubernetes cluster might be in EKS Stack. I will write another blog post on managing and designing Multi-Stack CDK projects, so stay tuned.

AWS SSM Parameter Store can also be used to manage Cross-Stack references. https://docs.aws.amazon.com/cdk/v2/guide/get_ssm_value.html

Cross-Stack References in CDK was originally published in TysonWorks on Medium, where people are continuing the conversation by highlighting and responding to this story.

AWS CloudWatch Internet Monitor is a service that helps you monitor the availability and performance of your internet-facing applications. It does this by sending probes to your application from different locations around the world, and then measuring the latency, and packet loss of the connections.

CloudWatch Internet Monitor uses a global network of probes to monitor the internet. These probes are located in different cities around the world, and they are connected to the internet through different networks. When you create an internet monitor, CloudWatch Internet Monitor will select a set of probes that are closest to your application. These probes will then send requests to your application, and CloudWatch Internet Monitor will measure the performance of the connections.

With CloudWatch Internet Monitor, we can monitor the following metrics.

Availability: CloudWatch Internet Monitor can detect when your application is unavailable. It does this by sending probes to your application at regular intervals. If a probe fails to connect to your application, CloudWatch Internet Monitor will send you an alert.

Performance: CloudWatch Internet Monitor can measure the performance of your application. It does this by measuring the latency, jitter, and packet loss of the connections between the probes and your application.

Geolocation: CloudWatch Internet Monitor can track the location of your users. It does this by measuring the IP addresses of the users who connect to your application.

ISPs: CloudWatch Internet Monitor can track the ISPs of your users. It does this by measuring the AS numbers of the networks that the users are connected to.

Key Components:

Monitor: A monitor serves as the receptacle for your established parameters, designating which resources are subject to observation.

Health Event: In instances where the Internet Monitor identifies noteworthy degradation in your network performance, it initiates a health event. Each such event provides detailed information about the affected client locations and the involved Internet Service Providers (ISPs).

Performance and Availability Scores (Health Scores): These are statistical approximations of the fraction of traffic to your application that remains unaffected by any dips in performance or availability. These scores can also be accessed as metrics in CloudWatch.

CloudWatch Logs: Catering to the locations and network providers that are particular to your clients, the Internet Monitor disseminates measurements to CloudWatch Logs. These measurements encompass performance and availability scores, the volume of data transferred, and the round-trip time (RTT).

Now that we know what Internet Monitor is, let’s create a simple monitor and experience the product.

Head over to CloudWatch Console, click on the Internet Monitors tab, then click Create Internet Monitor button.

Wait for a while for data to be collected. The check the CloudWatch Console.

Internet Monitor also logs each event to CloudWatch Logs.

Let’s check out the City one

That’s neat, you see traffic coming from all over the globe.

Don’t forget to remove the resources created in this tutorial. Click Disable Internet Monitor, then Delete.

AWS CloudWatch Internet Monitor is a powerful tool that can help you monitor the availability and performance of your internet-facing applications. It is easy to use and configure, and it provides a wealth of metrics that you can use to track the performance of your applications.

Monitor Your Internet-Facing Applications with AWS CloudWatch Internet Monitor was originally published in TysonWorks on Medium, where people are continuing the conversation by highlighting and responding to this story.

AWS Lambda is an excellent solution for handling cloud workloads without the need of managing complex infrastructure. There will be times you may need to make your Lambda function accessible to external users or services. In this blog post, I’ll explain three distinct approaches to expose Lambda Functions to the internet: API Gateway, Application Load Balancer, and Function URLs.

I always like to follow the “right tool for the right job” approach, which has served me well throughout my career.

API Gateway

Amazon API Gateway is a fully managed service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket APIs at any scale. It acts as a “front door” for applications to access data, business logic, or functionality from your backend services, such as workloads running on EC2, and Lambda.

Features

- API Mangement
- WebSocket Support
- Access Control via IAM, Cognito, OAuth2, Lambda Authorizer
- Deployment Strategies, including Canary releases
- Version Management
- OpenAPI Integration
- Web Application Framework(WAF) Integration
- Rate Limiting

In short, you would want to use API Gateway if you are looking for full-blown API framework where you will need rich features. Keep in mind, though, that the costs associated with API Gateway are higher compared to other options, but totally worth it in my opinion.

Application Load Balancer

AWS Application Load Balancer (ALB) is a fully managed service that provides Layer-7 load balancing for HTTP/HTTPS traffic to targets such as EC2 instances, Lambda Functions, ECS, and EKS based on request attributes like headers, HTTP methods, query string parameters, and source IP address CIDR.

Feaetures
- Advanced Routing Capabilities
- TLS Offloading
- Web Application Firewall (WAF) Integration
- Sticky Sessions
- HTTP/2 and gRPC support
- Access Control via Cognito and IAM

Consider using ALB if you want to use a Load Balancer to manage requests for your Lambda Functions without the need for a comprehensive API framework like API Gateway. ALB is also a suitable choice when performance is a factor if you have a high traffic workload.

Functions URLs

AWS Lambda Function URLs are built-in HTTPS endpoints that can be associated with a single Lambda function or function alias. They provide a simplified way to configure an HTTPS endpoint in front of your function without needing to learn, configure, and operate additional services like API Gateway or ALB.

Features
- Simple setup process
- Version support via mapping to function alias
- Authentication via IAM
- CORS Support

Function URLs are ideal for scenarios in which you need to deploy a single-function microservice with a public endpoint that doesn’t need features offered by API Gateway or ALB. Lambda Function URLs enable you to attach HTTPS endpoints to any Lambda function. Functions URLs are easy to set up, have no dependency on other cloud resources.

Now that we’ve explored each option, let’s discuss potential use cases for each one.

Backend for a SaaS business:

API Gateway: Ideal for situations where support for multiple versions of APIs, user authentication, rate limiting for bad actors, OpenAPI compatibility, and Canary deployments for gradual rollout of changes are necessary.

Microservices

Application Load Balancer: Best suited for a Microservice responsible for sending notifications to recipients. This microservice may be called by other applications, leading to high load. In such a scenario, it is essential to manage the load effectively, ensure performance, handle authentication, and have the ability for advanced routing and support for multiple targets.

Webhooks

Function URLs: The perfect choice for a webhook for external services when the goal is to minimize resource usage and overhead, or for form handlers that forward user-submitted form data. In both cases, Function URLs offer a simplified solution with reduced overhead.

In this short article I’ve discussed the options for exposing your Lambda functions to internet. Hopefully this can guide you choosing the right option for your use case.

Exposing AWS Lambda Functions to Internet? Here’s your options was originally published in TysonWorks on Medium, where people are continuing the conversation by highlighting and responding to this story.

The rise of ChatGPT and other generative AI technologies has started a significant amount of discussion around their potential to replace jobs. In this tutorial, I will explore the capabilities of ChatGPT by asking to generate common workloads on AWS. I will keep things fairly simple for this one, which could be expected from a Junior Cloud Solutions Architect.

Sorry for the clickbait title, the results are not shocking 🤷‍♂️

Let’s start with the first task. I will ask ChatGPT to use AWS CDK instead of CloudFormation, we don’t want to go over thousand lines of YAML/JSON (no thanks). CDK version 2.63.0 was used in the examples.

import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';

export class YourProjectNameStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create an S3 bucket for static website hosting
    const websiteBucket = new s3.Bucket(this, 'WebsiteBucket', {
      websiteIndexDocument: 'index.html',
      websiteErrorDocument: 'error.html',
      publicReadAccess: true,
      removalPolicy: cdk.RemovalPolicy.DESTROY, // NOT recommended for production
    });

    // Create a CloudFront distribution to serve the static website
    const distribution = new cloudfront.Distribution(this, 'Distribution', {
      defaultBehavior: { origin: new origins.S3Origin(websiteBucket) },
      defaultRootObject: 'index.html',
    });

    // Output the S3 bucket and CloudFront distribution domain names
    new cdk.CfnOutput(this, 'BucketDomainName', {
      value: websiteBucket.bucketWebsiteDomainName,
    });
    new cdk.CfnOutput(this, 'DistributionDomainName', {
      value: distribution.distributionDomainName,
    });
  }
}

Construct base class was moved to separate module called ‘constructs’ in v2 version of the CDK. Although ChatGPT is importing v2 modules, it tried to use v1 ‘cdk.Construct’ class instead.

import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';
import { Construct } from 'constructs'

export class YourProjectNameStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {

Overall I give ChatGPT 8/10 here. It’s a quick fix if you know what you are looking for, but it can confuse beginners.

Let’s continue with the second task.

import * as cdk from 'aws-cdk-lib';
import * as cognito from 'aws-cdk-lib/aws-cognito';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigatewayv2 from 'aws-cdk-lib/aws-apigatewayv2';
import * as authorizers from 'aws-cdk-lib/aws-apigatewayv2-authorizers';

export class YourProjectNameStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create a Cognito User Pool
    const userPool = new cognito.UserPool(this, 'UserPool', {
      selfSignUpEnabled: true,
      signInAliases: {
        email: true,
      },
      autoVerify: {
        email: true,
      },
    });

    // Create a Lambda Function
    const lambdaFunction = new lambda.Function(this, 'MyFunction', {
      runtime: lambda.Runtime.NODEJS_14_X,
      handler: 'index.handler',
      code: lambda.Code.fromInline(`
        exports.handler = async (event) => {
          console.log('Event:', JSON.stringify(event, null, 2));
          return {
            statusCode: 200,
            body: JSON.stringify({ message: 'Success' }),
          };
        };
      `),
    });

    // Create a REST API using API Gateway
    const httpApi = new apigatewayv2.HttpApi(this, 'MyApi', {
      apiName: 'my-api',
      corsPreflight: {
        allowOrigins: apigatewayv2.Cors.ALL_ORIGINS,
        allowMethods: apigatewayv2.Cors.ALL_METHODS,
      },
      defaultAuthorizer: new authorizers.HttpUserPoolAuthorizer({
        userPool,
      }),
    });

    // Add a route for the Lambda function
    httpApi.addRoutes({
      path: '/my-function',
      methods: [apigatewayv2.HttpMethod.ANY],
      integration: new apigatewayv2_integrations.HttpLambdaIntegration({
        handler: lambdaFunction,
      }),
    });

    // Output the User Pool ID, REST API endpoint, and Lambda function ARN
    new cdk.CfnOutput(this, 'UserPoolId', {
      value: userPool.userPoolId,
    });
    new cdk.CfnOutput(this, 'ApiEndpoint', {
      value: httpApi.url!,
    });
    new cdk.CfnOutput(this, 'LambdaFunctionArn', {
      value: lambdaFunction.functionArn,
    });
  }
}

ChatGPT is making the same mistakes here, but this time with multiple modules. Outside of the Construct issue I’ve mentioned above, we have now issues with the ‘apigatewayv2’ and ‘authorizers’ modules. It tries to use experimental features that don’t exist in the modules we are importing.

Here’s how I would do it, without using the experimental L2 Construct Library.

import * as cdk from 'aws-cdk-lib';
import * as cognito from 'aws-cdk-lib/aws-cognito';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigw from 'aws-cdk-lib/aws-apigateway';

import { Construct } from "constructs"

export class YourProjectNameStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create a Cognito User Pool
    const userPool = new cognito.UserPool(this, 'MyUserPool', {
      userPoolName: 'my-user-pool',
      selfSignUpEnabled: true,
      signInAliases: {
        email: true,
        phone: false,
        username: true,
      },
      autoVerify: {
        email: true,
      },
    });

    // Create a Lambda function that logs incoming events and returns a "Success" message
    const logEventsFunction = new lambda.Function(this, 'LogEventsFunction', {
      runtime: lambda.Runtime.NODEJS_14_X,
      handler: 'index.handler',
      code: lambda.Code.fromInline(`
        exports.handler = async (event) => {
          console.log('Event:', JSON.stringify(event, null, 2));
          return {
            statusCode: 200,
            body: JSON.stringify({ message: 'Success' }),
          };
        };
      `),
    });

    // Create a REST API using API Gateway
    const api = new apigw.RestApi(this, 'MyApi', {
      restApiName: 'My API',
      defaultCorsPreflightOptions: {
        allowOrigins: apigw.Cors.ALL_ORIGINS,
        allowMethods: apigw.Cors.ALL_METHODS,
        allowHeaders: ['*'],
      },
    });

    // Use Cognito User Pool for REST API Authorizer
    const authorizer = new apigw.CfnAuthorizer(this, 'MyApiAuthorizer', {
      restApiId: api.restApiId,
      name: 'MyAuthorizer',
      type: apigw.AuthorizationType.COGNITO,
      identitySource: 'method.request.header.Authorization',
      providerArns: [userPool.userPoolArn],
    });

    // Serve HTTP requests for the Lambda function
    const lambdaIntegration = new apigw.LambdaIntegration(logEventsFunction);
    const logEventsResource = api.root.addResource('logEvents');
    logEventsResource.addMethod('POST', lambdaIntegration, {
      authorizationType: apigw.AuthorizationType.COGNITO,
      authorizer: { authorizerId: authorizer.ref },
    });

    // Output the User Pool ID, REST API endpoint, and Lambda function ARN
    new cdk.CfnOutput(this, 'UserPoolId', {
      value: userPool.userPoolId,
    });
    new cdk.CfnOutput(this, 'ApiEndpoint', {
      value: api.url,
    });
    new cdk.CfnOutput(this, 'LambdaFunctionArn', {
      value: logEventsFunction.functionArn,
    });
  }
}

I give ChatGPT 6/10 for this one, if you are not comfortable with CDK, you could spend hours fixing the template.

Let’s move on the final task.

import * as cdk from 'aws-cdk-lib';
import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as cognito from 'aws-cdk-lib/aws-cognito';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';

export class YourProjectNameStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create a Cognito User Pool
    const userPool = new cognito.UserPool(this, 'MyUserPool', {
      userPoolName: 'my-user-pool',
      selfSignUpEnabled: true,
      signInAliases: {
        email: true,
        phone: false,
        username: true,
      },
      autoVerify: {
        email: true,
      },
    });

    // Create an AppSync API
    const api = new appsync.GraphqlApi(this, 'MyApi', {
      name: 'my-api',
      schema: appsync.Schema.fromAsset('graphql/schema.graphql'),
      authorizationConfig: {
        defaultAuthorization: {
          authorizationType: appsync.AuthorizationType.USER_POOL,
          userPoolConfig: {
            userPool,
          },
        },
      },
      xrayEnabled: true,
    });

    // Create a DynamoDB table
    const table = new dynamodb.Table(this, 'MyTable', {
      partitionKey: { name: 'id', type: dynamodb.AttributeType.STRING },
    });

    // Create a data source for the AppSync API
    const dataSource = api.addDynamoDbDataSource('MyDataSource', table);

    // Add a GraphQL resolver for the data source
    dataSource.createResolver({
      typeName: 'Query',
      fieldName: 'getItems',
      requestMappingTemplate: appsync.MappingTemplate.dynamoDbScanTable(),
      responseMappingTemplate: appsync.MappingTemplate.dynamoDbResultList(),
    });

    // Output the AppSync API URL and Cognito User Pool ID
    new cdk.CfnOutput(this, 'GraphqlApiUrl', {
      value: api.graphqlUrl,
    });

    new cdk.CfnOutput(this, 'UserPoolId', {
      value: userPool.userPoolId,
    });
  }
}

ChatGPT is off again, this time by a large margin. Here’s you would accomplish the same task without using the experimental L2 Construct Library

import * as cdk from 'aws-cdk-lib';
import * as cognito from 'aws-cdk-lib/aws-cognito';
import * as appsync from 'aws-cdk-lib/aws-appsync';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as iam from "aws-cdk-lib/aws-iam";
import { readFileSync } from "fs";
import { Construct } from "constructs";

export class YourProjectNameStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create a Cognito User Pool
    const userPool = new cognito.UserPool(this, 'MyUserPool', {
      userPoolName: 'my-user-pool',
      selfSignUpEnabled: true,
      signInAliases: {
        email: true,
        phone: false,
        username: true,
      },
      autoVerify: {
        email: true,
      },
    });

    // Create a DynamoDB table
    const table = new dynamodb.Table(this, 'MyTable', {
      tableName: 'my-table',
      partitionKey: { name: 'id', type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

    // Create AppSync GraphQL API with Cognito User Pool as the authorizer
    const api = new appsync.CfnGraphQLApi(this, 'MyApi', {
      name: 'my-api',
      authenticationType: "AMAZON_COGNITO_USER_POOLS",
      userPoolConfig: {
        userPoolId: userPool.userPoolId,
        awsRegion: this.region
      },
    });

    const schema = new appsync.CfnGraphQLSchema(this, "graphql-api-schema", {
      apiId: api.attrApiId,
      definition: readFileSync("./schema.graphql").toString(),
    });
    schema.addDependsOn(api);

    const tableRole = new iam.Role(this, 'dynamo-role', {
      assumedBy: new iam.ServicePrincipal('appsync.amazonaws.com')
    });
    tableRole.addManagedPolicy(iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonDynamoDBFullAccess'));

    const dataSource = new appsync.CfnDataSource(this, 'ItemsDataSource', {
      apiId: api.attrApiId,
      name: 'table-source',
      type: 'AMAZON_DYNAMODB',
      dynamoDbConfig: {
        tableName: table.tableName,
        awsRegion: this.region
      },
      serviceRoleArn: tableRole.roleArn
    });

    const getAllResolver = new appsync.CfnResolver(this, 'GetAllQueryResolver', {
      apiId: api.attrApiId,
      typeName: 'Query',
      fieldName: 'all',
      dataSourceName: dataSource.name,
      requestMappingTemplate: `{
        "version": "2017-02-28",
        "operation": "Scan",
        "limit": $util.defaultIfNull($ctx.args.limit, 20),
        "nextToken": $util.toJson($util.defaultIfNullOrEmpty($ctx.args.nextToken, null))
      }`,
      responseMappingTemplate: `$util.toJson($ctx.result)`
    });
    getAllResolver.addDependsOn(schema);

    // Add the rest of the resolvers

    new cdk.CfnOutput(this, 'GraphqlApiUrl', {
      value: api.attrGraphQlUrl as string,
    });

    new cdk.CfnOutput(this, 'UserPoolId', {
      value: userPool.userPoolId,
    });
  }
}

I give it 5/10 here. It will take some time to fix and will confuse you again. I would say you are better off starting from scratch for this one.

Overall ChatGPT can be helpful guiding you through implementing different workloads. In our case we had to manually intervene and fix the issues. I would advise against beginners relying on ChatGPT or other AI tools to complete their tasks without first grasping the fundamentals.

I asked ChatGPT to Generate AWS Templates. Results are Shocking. was originally published in TysonWorks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

TLS is a proposed Internet Engineering Task Force (IETF) standard, first defined in 1999, and the current version is TLS 1.3, defined in August 2018.

AWS Application Load Balancer (ALB) now supports version 1.3 of the Transport Layer Security (TLS) protocol, enabling you to optimize the performance of your backend application servers while helping to keep your workloads secure. TLS 1.3 on ALB works by offloading encryption and decryption of TLS traffic from your application servers to the load balancer. TLS 1.3 is optimized for performance and security by using one round trip (1-RTT) TLS handshakes, and only supporting ciphers that provide perfect forward secrecy.

Using TLS with ALB provides you with the tools to more easily manage your application security, enabling you to improve the security posture of your applications. ALB allows you to centralize the deployment of SSL certificates using ALB’s integration with AWS Certificate Manager (ACM) and AWS Identity and Access Management (IAM). You can also analyze TLS traffic patterns and troubleshoot issues using ALB TLS metrics and access logs. ALB also allows you to use predefined security polices, which control the ciphers and protocols that your ALB presents to your clients.

To update your security policy to TLS 1.3, you can modify existing listeners through the EC2 console or by using the AWS CLI, call the ‘modify-listener’ command.

Are you ready to enhance your AWS Cloud journey? Head over to our website and book a free consultation call.

TLS 1.3 Support for Application Load Balancer was originally published in TysonWorks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Amazon Web Services (AWS) offers two services for sending emails: Simple Email Service (SES) and Pinpoint. While both services allow you to send emails, they cater to slightly different use cases and offer different features. Here is a comparison of AWS SES and AWS Pinpoint:

Purpose and focus:

• AWS SES is primarily focused on providing a simple, cost-effective, and reliable email sending service for both transactional and marketing emails. It is best suited for developers and businesses who need a straightforward way to send emails programmatically from their applications or systems.
• AWS Pinpoint, on the other hand, is a multi-channel marketing communication service that supports email, SMS, push notifications, and in-app messaging. Its primary focus is on targeted and personalized customer engagement, making it a better choice for businesses that require more sophisticated customer communication strategies.

Features:

• AWS SES provides features such as content filtering, dedicated IP addresses, feedback loops, and integration with AWS services like Lambda and S3. It also offers email templates, sending authorization, and reputation management.
• AWS Pinpoint offers additional features such as customer segmentation, campaign management, A/B testing, analytics, and event tracking. These features make it more suitable for advanced marketing campaigns and customer engagement efforts.

Pricing:

• AWS SES has a simple pricing model that is mainly based on the number of emails sent and the amount of data transferred. It offers a free tier with 62,000 emails per month for customers using Amazon EC2.
• AWS Pinpoint pricing is slightly more complex, as it depends on the channels used (email, SMS, push notifications) and the number of messages sent. For email, it has a pay-as-you-go model based on the number of emails sent and data transferred. There is a free tier with 62,000 emails per month for customers using Amazon EC2.

Ease of use:

• AWS SES is developer-focused and requires some programming skills to integrate it into applications, though it provides APIs and SDKs for popular programming languages.
• AWS Pinpoint provides a user-friendly interface and a RESTful API, making it easier for marketing teams to create and manage campaigns without the need for extensive technical knowledge.

In summary, if your primary need is a reliable and cost-effective email sending service for transactional or marketing emails, AWS SES is the better choice. However, if you require advanced features like customer segmentation, campaign management, and multi-channel support for more sophisticated customer engagement, AWS Pinpoint would be a better fit.

Are you ready to enhance your AWS Cloud journey? Head over to our website and book a free consultation call.

AWS SES vs AWS Pinpoint was originally published in TysonWorks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Amazon Simple Queue Service (SQS) is a fully managed, scalable, and reliable message queue service designed to help decouple and scale microservices, distributed systems, and Serverless applications. While it offers various benefits, it’s essential to be aware of the common pitfalls and best practices to make the most out of SQS. In this article I will discuss common SQS mistakes and how to fix them.

Pitfalls and Best Practices

Inappropriate use of visibility timeout:

Pitfall: The visibility timeout is the time during which a message is invisible to other consumers after being consumed. Setting an inadequate visibility timeout can lead to either message duplication or message loss.

Best Practice: Determine the appropriate visibility timeout based on the expected processing time of your application. Consider using Amazon CloudWatch to monitor your message processing time and adjust the visibility timeout accordingly.

Over-relying on the default configuration:

Pitfall: Relying solely on default settings may not meet your application’s specific requirements, which can lead to inefficiencies and bottlenecks.

Best Practice: Customize the settings, such as message retention period, visibility timeout, and delivery delay, according to your application’s needs. This helps ensure that the queue operates efficiently and effectively.

Inefficient long polling:

Pitfall: Short polling can lead to increased costs and high CPU utilization due to frequent, empty receive requests.

Best Practice: Utilize long polling to reduce the number of empty responses and minimize costs. Adjust the ReceiveMessageWaitTimeSeconds parameter to an optimal value based on your application’s requirements.

Ignoring dead-letter queues:

Pitfall: Continuously retrying to process faulty messages without a proper dead-letter queue (DLQ) can lead to an infinite loop, wasting resources and time.

Best Practice: Implement DLQs to handle failed message processing, allowing your application to focus on processing new messages. Monitor the DLQ to identify problematic messages and address any underlying issues.

Not monitoring and scaling queues:

Pitfall: Failing to monitor the health and performance of your SQS queues can lead to bottlenecks and decreased throughput.

Best Practice: Use Amazon CloudWatch to monitor your queues and set up alarms for important metrics like ApproximateNumberOfMessagesVisible and ApproximateNumberOfMessagesNotVisible. Use AWS Auto Scaling or AWS Lambda to scale your application based on the monitored metrics.

Insecure IAM policies:

Pitfall: Overly permissive IAM policies can expose your queues to unauthorized access or manipulation.

Best Practice: Implement the principle of least privilege and grant only necessary permissions to your IAM roles and policies. Use service-linked roles for AWS services that interact with your SQS queues.

Not handling message ordering:

Pitfall: Standard SQS queues do not guarantee the order of messages, which may lead to unexpected processing results.

Best Practice: Use FIFO (First-In-First-Out) queues if your application relies on message ordering. Keep in mind that FIFO queues come with additional limitations, such as a lower throughput compared to standard queues.

AWS SQS is an essential service for decoupling and scaling distributed systems, but its effective use requires understanding and avoiding common pitfalls. Implementing the best practices outlined in this article can help optimize your SQS implementation and avoid potential issues, enabling your application to run smoothly and efficiently.

Are you ready to enhance your AWS Cloud journey? Head over to our website and book a free consultation call.

SQS Pitfalls & Best Practices was originally published in TysonWorks on Medium, where people are continuing the conversation by highlighting and responding to this story.