DEV Community: Airat Yusuff

Monitoring Java APIs with Amazon CloudWatch and AWS X-Ray

Airat Yusuff — Thu, 14 Aug 2025 20:05:26 +0000

I recently started a “Smart Skill” training on Cloud Academy to learn more about monitoring and observability, as these are some essentials for anyone working within DevOps/Platform engineering. Having used platforms like Splunk for incident investigations, I wanted to learn more about AWS service offerings for observability (and that led me to the lab on AWS X-Ray).

In this post, I’ll be sharing an end-to-end process of how to configure a Java API deployed on an EC2 instance, monitor logs using Amazon CloudWatch and traces with AWS X-Ray.

Note: Although the lab provided a decent starting baseline, I reconfigured it, so they can be considered two different projects and you can try working on both.

Project Overview

A Java API with /post and /get endpoints to save 4 rows of data to a DynamoDB table, and fetch each row using its ID; deployed on an EC2 instance and configured to use CloudWatch agent and X-Ray daemon for logging and tracing.

Architecture

Setup

Open JDK 11
Maven
AWS X-Ray Daemon
Amazon CloudWatch agent
EC2
IAM

Pre-Requisites

Familiarity with Java and/or building Java APIs (useful for debugging)
An existing DynamoDB table for the API to store/retrieve data
Familiarise with app code: GitHub repo

The project can be setup using some automation with Terraform and Ansible, but this will be the manual deployment/configuration documentation because I wanted to work through each step and explore along the way.

1) AWS Setup

Minimal EC2 Settings

Name: xray-api
AMI: Ubuntu latest version
Instance type: t3 medium
Create your Key pair (or use an existing one, if you have one)
Security group: allow inbound traffic on SSH (port 22) and custom TCP for Tomcat (port 8080)
Defaults for everything else

An IAM role is also needed for the EC2 instance to have access to perform tasks relating to DynamoDB, X-Ray and CloudWatch. Ensure to attach the IAM role to the instance, so that it can assume the role.

// Trusted Entity - allows EC2 to perform the actions defined in the policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

// Permissions Policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DynamoDBLimitedAccess",
            "Effect": "Allow",
            "Action": [
                "dynamodb:PutItem",
                "dynamodb:DeleteItem",
                "dynamodb:GetItem",
                "dynamodb:Scan",
                "dynamodb:Query",
                "dynamodb:UpdateItem"
            ],
            "Resource": "<<ARN for your DynamoDB table>>"
        },
        {
            "Sid": "PermissionForXRayDaemon",
            "Effect": "Allow",
            "Action": [
                "xray:PutTraceSegments",
                "xray:PutTelemetryRecords"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Once your instance is all setup and ready, SSH into the instance with your key pair.

2) Configure Instance

Install Java and configure paths

wget https://clouda-labs-assets.s3-us-west-2.amazonaws.com/aws-xray/openjdk-11%2B28_linux-x64_bin.tar.gz -O openjdk-11+28_linux-x64_bin.tar.gz
tar -xvf openjdk-11+28_linux-x64_bin.tar.gz
sudo mkdir -p /usr/lib/jvm
sudo mv jdk-11* /usr/lib/jvm/java-11-openjdk     


export JAVA_HOME=/usr/lib/jvm/java-11-openjdk
export PATH=$JAVA_HOME/bin:$PATH
echo 'export JAVA_HOME=/usr/lib/jvm/java-11-openjdk' >> ~/.bash_profile
echo 'export PATH=$JAVA_HOME/bin:$PATH:$HOME/.local/bin:$HOME/bin' >> ~/.bash_profile
source ~/.bash_profile

# check jdk version is 11
java -version

Install Maven

wget https://archive.apache.org/dist/maven/maven-3/3.9.6/binaries/apache-maven-3.9.6-bin.tar.gz
tar -xzf apache-maven-3.9.6-bin.tar.gz
sudo mv apache-maven-3.9.6 /opt/maven
echo 'export MAVEN_HOME=/opt/maven' >> ~/.bash_profile
echo 'export PATH=$MAVEN_HOME/bin:$PATH' >> ~/.bash_profile
source ~/.bash_profile

# check Maven version
mvn -v

Install AWS X-Ray Daemon

wget https://clouda-labs-assets.s3-us-west-2.amazonaws.com/aws-xray/aws-xray-daemon-linux-3.2.0.zip
sudo apt install unzip
unzip aws-xray-daemon-linux-3.2.0.zip

Configure CloudWatch (CW) agent

# Install CW agent
wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb
sudo dpkg -i amazon-cloudwatch-agent.deb

# create CW config file: this will create log groups for the API and X-Ray logs 
# (which will be collected from logs stored in files configured for the X-Ray and API system services
cat > /home/ubuntu/cw-config.json << 'EOF'
{
  "agent": {
    "metrics_collection_interval": 60,
    "logfile": "/var/log/cw-agent.log"
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/home/ubuntu/api.log",
            "log_group_name": "xray-api-logs",
            "log_stream_name": "{instance_id}-app",
            "timestamp_format": "%d-%m-%Y %H:%M:%S"
          },
          {
            "file_path": "/home/ubuntu/xray-daemon.log",
            "log_group_name": "aws-xray-logs",
            "log_stream_name": "{instance_id}-xray",
            "timestamp_format": "%d-%m-%Y %H:%M:%S"
          }
        ]
      }
    }
  }
}
EOF

# Start running CW agent
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/home/ubuntu/cw-config.json -s

Clone app from GitHub and setup

# Clone
git clone https://github.com/khairahscorner/xray-app.git

# Set properties
cp xray-app/src/main/resources/application-example.properties application.properties
sudo chmod a+w application.properties

# Add needed variables to the properties file
aws.region=<value>
dynamodb.table=<value>

# Package JAR
cd xray-app
mvn package
mv target/xray-app-1.jar target/app.jar #rename jar file

Setup System Service files

# service file for the X-Ray daemon
sudo cat > /etc/systemd/system/xray_daemon.service << 'EOF'
[Unit]
Description=AWS X-Ray Daemon
After=network.target

[Service]
ExecStart=/home/ubuntu/xray --region eu-west-2
Restart=always
User=ubuntu
StandardOutput=file:/home/ubuntu/xray-daemon.log
StandardError=file:/home/ubuntu/xray-daemon.log

[Install]
WantedBy=multi-user.target
EOF

# service file for the Java API itself
sudo cat > /etc/systemd/system/java_api.service << 'EOF'
[Unit]
Description=XRay Java API
After=network.target

[Service]
User=ubuntu
ExecStart=/usr/lib/jvm/java-11-openjdk/bin/java -jar /home/ubuntu/xray-app/target/app.jar --spring.config.location=file:/home/ubuntu/application.properties
SuccessExitStatus=143
Restart=on-failure
RestartSec=10
StandardOutput=file:/home/ubuntu/api.log
StandardError=file:/home/ubuntu/api.log

[Install]
WantedBy=multi-user.target
EOF

Start Services

# Start X-Ray Daemon
sudo systemctl daemon-reload
sudo systemctl enable xray_daemon
sudo systemctl start xray_daemon

# Start Java API service
sudo systemctl daemon-reload
sudo systemctl start java_app
sudo systemctl enable java_app

# check service statuses
sudo systemctl status xray_daemon
sudo systemctl status java_app

3) Deployed App

You should now be able to access the app with the instance iP address/DNS:

http://<public ip address/dns>:8080/post

http://<public ip address/dns>:8080/get?id=1

X-Ray Traces

Tracing makes it easy to spot failed endpoint calls, it also logs minimal details for requests that completed successfully.

CloudWatch Logs

Configuring the CloudWatch agent was a last minute add-on because I wanted to store the app logs somewhere more visible than a file within the instance. I configured the agent to collect the logs from both the api and daemon log files, and this gave me an overview of how log groups keep logs separate and organised.

Troubleshooting

I ran into quite a number of issues but resolved them by spending considerable time with AWS SDK documentation and ChatGPT (mostly debugging the Java code that I modified).

Overall:

ensure you have configured the IAM role with the right access permissions for all the necessary services and attached it correctly to the EC2 instance
If you’re modifying the app code, ensure it still works correctly with AWS Java SDK v2. You can test the app locally to verify but have AWS SSO or access keys configured locally.

Useful References:

AWS Authentication with SDK for Java

Migrating AWS Java SDK v1 to v2

SDK Credential Providers

Conclusion

With this project, I’m a bit more comfortable using X-Ray for traces and sending logs over to CloudWatch. The automated version will allow me to get a refresher on working with Ansible, so that’s up next!

Thanks for reading!

Till Next Time

Leveraging Lambda Functions (with Amazon SNS, S3 & EventBridge)

Airat Yusuff — Mon, 28 Jul 2025 13:06:39 +0000

For the longest time, I couldn’t quite grasp or fully understand how serverless services on AWS like Lambda functions ACTUALLY work in real-world scenarios and products. Partly because I wasn’t too familiar with event-driven architecture or built projects that fully implemented it.

That has now changed because I finally took some time to explore it with a scenario use-case. In this post, you’ll learn how to use AWS Lambda, S3, Amazon SNS, and EventBridge to build yourself a nice little weather alert system.

Project Summary

I modified the second project of the #DevOpsAllStarsChallenge (mainly because I didn’t want to use the sports data API) so instead, I built a notification system that sends email alerts of weather data for the city of Manchester, UK. It’s made up of:

a Lambda function that sends a summary of the current weather data for the city to a user email subscribed to an SNS topic; this is hooked up to an EventBridge rule with a morning, afternoon and evening schedule.
another Lambda function that retrieves the most recently added weather data file to the S3 bucket from this project and sends the summary to the user email subscribed to the same SNS topic; it is triggered whenever a new search is made via the dashboard and saved to storage.

You can read the full project and its feature summary here.

Architecture

One thing I’ve kept in mind since I started the challenge is to not underestimate the power of putting together an architectural diagram. It may not be the best but I quickly realised that drawing up a solution has helped me visualise and build out the projects better.

This was the first diagram I drew but eventually switched to using native S3 Event notifications for the fetch from S3 function for reasons explained further below (but I still included how to set up the approach in the diagram).

Build Process

I first tried building it all out via the AWS console but as with the first project, I wrote scripts to build it all using aws-cli commands instead. The aws-cli documentation was my main source of truth and I learnt a lot navigating my way around for the different services I needed for the project.

I wrote a brief note on how I worked through each section of the architecture here.

Repo structure:

Gotchas

I fell into the trap of not specifying the —region option so many times. I was working in the eu-west-2 region but I still haven’t updated my IDE’s credentials and config files from us-east-1, so I spent a lot more time resolving errors that eventually turned out to be region mismatches.
Pay extra attention when creating policies and roles, one can easily make mistakes inlining policy documents with JSON formats.
It got a bit tricky creating the Lambda functions via aws-cli commands, especially with adding the function code. I had to ensure that I created the .zip files with the most updated versions of the code files; the names used also need to match the handlers defined for the functions + the main execution methods in the code.

e.g For alerts_lambda.py that uses a process() function for the main execution, the zip file was named alerts_lambda and the handler in my scripts was alerts_lambda.process:

 aws lambda create-function --function-name $Function1Name --runtime python3.9 \
        --zip-file fileb://src/alerts_lambda.zip --handler alerts_lambda.process \
        --timeout 10 --role arn:aws:iam::${AWS_ACCOUNT_ID}:role/$Function1RoleName

The biggest problem I encountered definitely has to be setting up the EventBridge rules: I couldn’t get the rule using an S3 event pattern to work! Despite trying many fixes, it just wasn’t invoking the Lambda function when an object gets placed in the bucket.

Turns out that I had completely ignored the alert clearly informing users to turn on the configuration that allows S3 buckets to send notifications to EventBridge for all events that occur within the bucket (perk of using the management console, I guess).

In hindsight, the entire ordeal made me learn about the optimal choice to consider when you need to invoke Lambda functions with simple S3 event triggers: S3 Event Notifications.

S3 Event Notifications

This is a more native approach that can be used to configure what should happen when specified events occur within a S3 bucket. The destinations can be services like Lambda, SNS, or even EventBridge. In this case, I wanted to invoke the Lambda function that handles the data retrieval, preprocessing and sending to SNS, so Lambda it was.

Another benefit of using this approach is its near-instant “activation”. With an EventBridge rule, there might be some delay before it starts working. EventBridge is also better suited for complex event patterns but this was just a simple case of monitoring for the addition of new objects to a S3 bucket.

However, this does not mean it cannot be implemented using EventBridge; just ensure to turn on the configuration mentioned above.

Setup with S3 Event Notification

aws s3api put-bucket-notification-configuration \
    --bucket $BUCKET_NAME --region $AWS_REGION \
    --notification-configuration '{
        "LambdaFunctionConfigurations": [
            {
                "LambdaFunctionArn": "arn:aws:lambda:'"$AWS_REGION"':'"$AWS_ACCOUNT_ID"':function:'"$FunctionName"'",
                "Events": ["s3:ObjectCreated:*"]
            }
        ]
    }'

Setup with EventBridge using event pattern


EVENT_PATTERN=$(cat <<EOF
{
  "source": ["aws.s3"],
  "detail-type": ["Object Created"],
  "detail": {
    "bucket": {
      "name": ["$BUCKET_NAME"]
    }
  }
}
EOF
)

aws events put-rule --name $TRIGGER_NAME --event-pattern "$EVENT_PATTERN" --region $AWS_REGION

aws events put-targets --rule $TRIGGER_NAME \
        --targets "Id"="1","Arn"="arn:aws:lambda:$AWS_REGION:$AWS_ACCOUNT_ID:function:$FunctionName"

aws lambda add-permission \
        --function-name $FunctionName \
        --statement-id $EventBridgePermissionStatementId \
        --action "lambda:InvokeFunction" \
        --principal "events.amazonaws.com" \
        --source-arn "arn:aws:events:$AWS_REGION:$AWS_ACCOUNT_ID:rule/$TRIGGER_NAME" \
        --region $AWS_REGION

aws s3api put-bucket-notification-configuration --bucket $BUCKET_NAME --region $AWS_REGION \
    --notification-configuration='{ "EventBridgeConfiguration": {} }'

Conclusions

This was a pretty good project and I’m glad I modified the idea and worked on it using both management console and aws-cli commands.

I’ll be skipping Project 3 as I was not that much interested in the services it uses; but definitely saved for when I might want to try it out.

Project 4 is also out now and it looks pretty good: uses ECS (Fargate) that I already tried here, services that I want to refresh my knowledge on (API Gateway, Load Balancing) and some other interesting ones for the enhancements.

Till Next time✨

Deploying Scalable APIs With Terraform and GitHub Actions

Airat Yusuff — Fri, 25 Jul 2025 16:02:57 +0000

Scalability is a fundamental concept to consider when building efficient cloud solutions. Along with security, they are highlighted in Well-Architected framework pillars like Cost Optimisation and Reliability. I explored these two concepts in the third project I built as part of the #DevOpsAllStarsChallenge.

In this post, you will learn how to deploy a scalable public-facing API using AWS services like API Gateway and Elastic Container Service (ECS). In a way, it enhances the first project for the challenge by rearchitecting the infrastructure for security and using extra tooling like:

Terraform to provision/manage the infrastructure, and
GitHub Actions for automated CD workflows.

Project Summary

I created a containerised API management system for querying weather data - a web API built with Flask. It exposes a /weather endpoint that takes a city query parameter (and if the parameter is not provided, it uses a default city value of Manchester).

Main Concepts Covered

API management with API Gateway and Application Load Balancers for security and scalability
Public and private subnetting architecture for enhanced resource protection
Infrastructure-as-Code with Terraform
Terraform state management with backend blocks (S3 type)
Continuous Deployment with GitHub Actions

Read more about the project on GitHub

Architecture

This architecture would also work without the API gateway i.e., the load balancer is internet-facing (in a public subnet), so it has an accessible DNS name. However, I wanted to try API gateway so it was a good opportunity to learn about restricting access to load balancers through security groups.

Repo Structure

Infrastructure Configuration

I used Terraform to provision the entire architecture, including the ECS service creation (which needs an image already pushed to ECR for the task definition). This will be covered further below.

All Terraform files can be found here.

Step 1: AWS Environment Setup

The following resources are set up within the aws_environment module:

1) custom VPC with public and private subnets: This was easy to set up using the Terraform AWS VPC module. You configure the module and Terraform will handle the creation of all relevant resources without needing to explicitly write the code yourself.

I chose 10.16.0.0/16 for the VPC (i.e., 65,536 available IP addresses from 10.16.0.0 to 10.16.255.255) and subnets (10.16.12.0/24, 10.16.24.0/24, 10.16.36.0/24 and 10.16.48.0/24 with 256 IP addresses each).

RFC 1918 on reserved ranges for private IP addresses
NAT gateway is enabled to ensure the resources in private subnets can communicate with resources placed in public subnets (or the internet).

2) Access management: IAM roles, policies to attach to the roles, security groups (allow only traffic from API gateway into load balancer, allow only traffic from load balancer into ECS service).

3) ECR repository for the container images.

Step 2: ECS Setup

Found in modules/ecs_setup:

1) Application Load Balancer, including target group and listener;

2) ECS: cluster, task definition for the service, and the service itself.

Step 3: API Gateway
Found in modules/api_gateway_setup:

1) All required configurations to create the gateway and integrate with the load balancer

2) Update security group for the load balancer to ensure it only allows incoming traffic from the API gateway IP ranges.

Continuous Deployment

I used GitHub Actions to automate the infrastructure deployment and management process. First, I outlined the jobs I wanted to run and the steps for each of them. This was continuously refined as I worked through the resources to be deployed.

Workflow Structure

I also experimented with managing deployments using GHA’s environments. This was a way of adding an extra level of authorisation with Terraform, by configuring the environment to have deployment protection rules.

In this instance, I added myself as a required reviewer; so for every run of the workflow, the aws_environment_setup job needs an approval because it uses the configured environment. Once approved, all jobs with terraform apply commands run with the auto-approval option specified in the command.

Debugging Issues

1) Terraform Syntax errors
If you are new to provisioning these resources with Terraform, you will rely a lot on the documentation; it takes a lot of time and effort to ensure you properly configure what you need.

2) Resources With Dependencies
I realised that I needed to split the way I provision the resources e.g the ECR repository needs to be already set up before I could run a script to create and push the API’s Docker image to the repo, and the image is then used for the ECS service task definition.

As a result, I had a job that ran a partial terraform apply with the -target option for aws_environment module, the next job runs the script, and the next job runs terraform apply as a whole to provision the rest of the infrastructure.

3) Remote Terraform State Management
This was one of the issues I spent quite some time on. Terraform uses state files to keep track of changes it has applied to provision infrastructure and new additions to the config files. However, this is different when running Terraform via GitHub Actions because the state files don’t get pushed to live.

I learnt about the usage of backend block to manage where Terraform stores its state files; but this was quite tricky because of the split provisioning I needed to do. Eventually, I was able to initialise the backend correctly (I used the S3 type, so the state file was stored in a S3 bucket).

terraform {
  backend "s3" {
    bucket = "devops-challenge-tf-state-files"
    key    = "files/terraform.tfstate"
    region = "eu-west-2"
  }
}

4) Gateway URL returning error messages
I encountered a network/endpoint error during one of the deployments, and it happened after I changed the cidr_block for my load balancer to only accept traffic from the public subnets (with the intention that it should only allow traffic from the gateway).

However, API Gateway is a fully managed service and it uses managed IPs i.e you did not configure them, so they are not within your custom VPC/subnets. It took me looking through my codes again to realise I never specified my VPC/subnets in my gateway configurations, so I could not assume the gateway resource was within my VPC.

Use aws_ip_ranges instead: a data source for getting IP ranges of AWS services. The downside however, is that it causes failures when running terraform destroy. I had to retrieve the IP addresses manually (from the workflow logs) to destroy my setup.

I also encountered ‘Missing Authentication Token’ errors when trying to access the gateway’s base URL or /health for load balancer health checks.

This was because you need to configure a resource, method, and integration for each endpoint.

Conclusions

This was a comprehensive project that required a lot of hours with lots of debugging; I was able to acquire new knowledge by building it incrementally and going back to improve it even more.

I still need to read more on:

how to configure an API gateway to route requests from its root url to the load balancer (and the service target group);
figure out how to retrieve the IP ranges for API gateway to restrict access to the load balancer;
how to configure health checks correctly.

I’d also want to explore these enhancements that use Elasticache and DynamoDB.

There have been more videos published for the challenge but thankfully, they are IaC versions of existing projects, so I’m not lagging behind much.

Till Next time✨

Build and Deploy Streamlit (Python) App on AWS ECS with Fargate

Airat Yusuff — Fri, 25 Jul 2025 15:44:01 +0000

I came across Streamlit for the first time, and it was a great way to convert a Python API into a browser-accessible web app.
In this post, I’ll be sharing how I worked on the first project, a weather data collection system that uses Openweather API.

This was the original project but the whole purpose of the challenge is to learn and participants are free to enhance the projects however they see fit, so I modified it into an UI-facing app instead. I also deployed the app into the AWS ecosystem and mostly used scripts to batch the entire process after knowing the steps I wanted to carry out.

Mine: https://github.com/khairahscorner/weather-dashboard

Concepts Covered

Python app development (Streamlit)
Infrastructure as Code (Python SDK, AWS CLI commands)
Cloud Storage (AWS S3)
Containerisation (Docker)
Container App Deployment (AWS ECS with Fargate)
CI/CD (GitHub Actions, AWS)

App Features

Fetches real-time weather data for any city of choice (input via UI)
Displays weather conditions like temperature (°F), humidity, etc
Automatically saves weather data as JSON files in AWS S3 with timestamps for historical tracking

1) Building and Running the App Locally

The full script was already provided, so I focused on modifying it to work as a Streamlit app; my full codes can be found on GitHub.

I modified the requirements.txt to include streamlit and one other dependency (pyarrow) that kept causing an issue.
Run python apps/scripts in virtual environments to ensure installed dependencies are isolated, so:

# Create an environment e.g named .venv
virtualenv -p python3 .venv

#activate
source .venv/bin/activate

Run pip install -r requirements.txt
Start app with streamlit run <file_name>

2) Running as a Container

Since I also wanted to deploy the app, I tried running it as a container, so I created a Dockerfile. You can also follow the instruction guide here.

FROM python:3.9-slim
COPY . /app
WORKDIR /app
RUN pip install --no-cache-dir -r requirements.txt
EXPOSE 8501
HEALTHCHECK CMD curl --fail http://localhost:8501/_stcore/health
ENTRYPOINT ["streamlit", "run", "dashboard.py", "--server.port=8501", "--server.address=0.0.0.0"]

Build the image and run (—-env-file needs to be specified so that your app knows where to look to load the environment variables).

# Build image
docker build -t streamlit_app . 

# Run container app
docker run --env-file .env -p 8501:8501 streamlit_app

3) Deploying to AWS

Since I wanted to deploy to AWS as a container app, some easy options were likely Elastic Beanstalk and App Runner. However, I wanted to practise working with Amazon ECS so I went with it instead.

AWS Guides on ECS

To deploy the app to ECS, you need to:

set up a repository in Amazon ECR and then push the image to the repository;
setup a task definition in ECS and create a cluster, then create a service in the cluster using the task definition.

There are some configurations that need to be done to use ECS but I had done something similar before (albeit unsuccessful), so these permissions and roles were already setup. However, I still added them in the scripts that I used.

Run the scripts using sh <script_name> in the correct order (all scripts used can be found here).

Everything worked successfully and I could access my running app via <ip-address>:8501 (that was the port I mapped in the task definition).

Note: using the IP address as-is leads to an issue when updating the service (forcing a new deployment to use the latest image for the task definition if your Docker image has been rebuilt).

The task is replaced hence the IP address changes, so the recommended approach is to configure and use a Load Balancer. This will route traffic to the right running task and its DNS name remains static, so there will be no need to worry about the changing IP addresses of the tasks

Enhancements

Setup an Application Load Balancer to properly route traffic from the running task without needing to look for its IP address.
Create a GHA workflow to run the scripts on push to repo (i.e rebuild the image, push, and update the service)

I also wanted to add a feature to retrieve five most recent data added to S3 for a specified city, but my focus was less on the app development and more on successfully working through the full end-to-end process i.e development to deployment.

Overall, I’m quite happy with my additions and I got to learn more about deploying containerised apps to ECS.

Next Up: Project 2 (Game Day Notification Solution)

State Management in React Using MobX State Tree (MST)

Airat Yusuff — Sat, 28 Sep 2024 11:00:00 +0000

If you are a React developer, you most likely work with different state management libraries like React Redux, Redux Toolkit, React Query, or even Zustand!

But, have you ever tried using MobX or MobX-State-Tree (MST)?

In this post, I'll share a brief overview of working with MST and why you should consider exploring the library for state management in your next project (+ why you probably may not!)

Brief Overview: What even is MobX-State-Tree?

MobX State Tree (MST for short) is a state management library that self-describes as offering "fully-featured reactive state management without the boilerplate".

Some of the features it offers out-of-box include: centralised stores for your data, ability to mutate data safely while also having access to trace those updates, runtime and static type checking, etc.

Useful Read:

MST Philosophy

Why Try It?

It's a lot less boilerplate than working with Redux!

If there was anything I really liked about using MST, it's the compactness and manageability. Of course, you can have large stores (trees) that are also part of a root store, but I found managing stores a lot easier with MST.

It's a lot less brainwork when you don't have to worry about defining constants as types for actions, or reducers that manage the states all in different files, not to mention managing them across multiple folders.

It also gives you a balance between mutability and immutability.

Immutability is one of the ways Redux safely handles data management, but that means having go through all of the above to update the 'immutable' data. On the other hand, MST provides a balance between the two. It's easier to update data within the protection measures the library offers.

Its official documentation also includes a pretty decent tutorial if you are new to using the library and would like to gain a basic understanding.

Why You Probably May Not Like It

Diving into MST can be proper confusing at first. I get it, I've been there before.

When you advance from the basic usage described in the tutorial and need it for a complex project or to utilise its advanced concepts, the official documentation is not the best to understand concepts, in my opinion. I found myself struggling a lot, and had to keep inferring my understanding from existing stores that had been defined in the project I was working on.

While it does seem to be a popular library, there's barely any engagement on Stack Overflow, so you might find yourself stuck and trying to figure out error messages yourself.

Not to be confused with MobX itself, which has slightly more questions and engagement.

It is also a very opinionated library with strict rules on how data should be structured and how trees interact with one another. While you may be familiar with many of the basic concepts if you've worked with state management libraries before (e.g views, actions), they have more complexities that make them work a bit differently (and can be frustrating at first).

It also has several new concepts that you will need to learn to maximise its "fully-featured" benefits (and you'll have to be the better judge for what works or does not work for your project).

Summary

I cannot say I fully understand how the library works yet, but so far, I have learned more about its usage and how to utilise it in projects. Working with an already established store design can also make it easier for you to figure out how to use its regular features.

In addition, despite being opinionated, the library still gives room for flexibility for developers to shape their store management in different ways based on preference. It also offers more features that can make state management easier, and reduces boilerplate.

Overall, one to consider incorporating into your next project.

P.S Some Bookmarks to help you navigate through the official documentation:

FAQs

Using MST with React

Learn about MST types

Automate Deployment to AWS App Runner Using Terraform

Airat Yusuff — Sat, 28 Sep 2024 03:12:36 +0000

Ever run into a situation where you manually deployed your API to AWS via the management console (one with lots of enviroment variables too!), only to realise you forgot to change the region of deployment?

It may not be the exact scenario but forgetting to switch regions for deployments can be a common occurrence; and in my case, I had previously deployed to us-east-1 but now needed the deployment to be eu-west-2. I tried to search for any console features that could allow me “copy” the service into the new region (or update the current region) but that did not seem to be available, so I was left with repeating the entire process. Using Infrastructure-as-code to automate provisioning of the AWS resources would have saved me from this situation, hence this blogpost.

In this post, I’ll be sharing the Terraform (and shell) scripts I wrote to automate the deployment of a Node.js (Express) API with environment variables, including a database deployed on AWS RDS with MySQL.

Prerequisites

A Node.js/Express API (e.g. one of my repos)
AWS account
Terraform installed on your local machine

Setup

This was my directory structure:

Note: As you will see below, I created shell scripts to run the necessary Terraform commands due to the number of environment variables I needed to add to the API service.

variables.tf

variable "api_name" {
  type = string
  default = # name you want to give to your api service
}

variable "github_repo" {
  type = string
  default = # your GitHub repo url
}

variable "apprunner_connection_arn" {
  type = string
}
variable "vpc_connector_arn" {
    type = string
}

variable "env_prod_db_username" {
  type = string
}
variable "env_prod_db_password" {
  type = string
}
variable "env_prod_fe_url" {
  type = string
}
# other variables

provider.tf

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "5.67.0"
    }
  }
}

provider "aws" {
  region = "eu-west-2"
}

output.tf

output "api_service_url" {
  value = aws_apprunner_service.express-api-service.service_url
}

output "api_service_arn" {
  value = aws_apprunner_service.express-api-service.arn
}

output "api_service_status" {
  value = aws_apprunner_service.express-api-service.status
}

main.tf

Prerequisites:

1) You need to have a connection to your repository provider (i.e GitHub or BitBucket) to enable access to that repo for App Runner; this can be done manually.

The ARN for this connection is what you need for var.apprunner_connection_arn.

2) You also need to create a VPC connector; this can be done with Terraform in this script. However, I had an existing VPC connector for the region, so the provisioning is not included in my script.

You can use the official documentation to set it up.


resource "aws_apprunner_service" "express-api-service" {
  service_name = var.api_name

  source_configuration {
    auto_deployments_enabled = true
    authentication_configuration {
      connection_arn = var.apprunner_connection_arn
    }

    code_repository {
      repository_url = var.github_repo
      source_code_version {
        type  = "BRANCH"
        value = "master" # or whichever branch you are deploying
      }
      code_configuration {
        configuration_source = "API"
        code_configuration_values {
          build_command = "npm install"
          port          = "8000" # or the port your api runs on
          runtime       = "NODEJS_16"
          start_command = "npm run start"
          runtime_environment_variables = {
            PROD_DB_PORT          = "3306"
            NODE_ENV              = "production"
            PROD_DB_PASSWORD      = var.env_prod_db_password
            PROD_DB_USERNAME      = var.env_prod_db_username
            PROD_FRONTEND_URL     = var.env_prod_fe_url
            # your other env variables
          }
        }
      }
    }
  }

  network_configuration {
    ingress_configuration {
      is_publicly_accessible = true
    }
    egress_configuration {
      egress_type       = "VPC"
      vpc_connector_arn = var.vpc_connector_arn
    }
  }

  instance_configuration {
    cpu    = "2048"  #2vCPU
    memory = "4096"  #4GB
  }

  health_check_configuration {
    interval = 10
    timeout = 5
  }

  tags = {
    DEPLOYED = "api-via-terraform"
  }
}

And that’s it! Run the necessary terraform commands with the scripts provided below:

terraform init
sh plan.sh for terraform plan and review if necessary
sh deploy.sh for terraform apply

Note: Before running these scripts, ensure to have the .env file with all the necessary environment variables.

plan.sh

#!/bin/bash

export $(grep -v '^#' .env | xargs)

terraform plan \
  -var="apprunner_connection_arn=$APPRUNNER_CONNECTION_ARN" \
  -var="vpc_connector_arn=$VPC_CONNECTOR_ARN" \
  -var="env_prod_db_username=$PROD_DB_USERNAME" \
  -var="env_prod_db_password=$PROD_DB_PASSWORD" \
  -var="env_prod_fe_url=$PROD_FRONTEND_URL" \
  # any other environment variables your API needs

deploy.sh

#!/bin/bash

export $(grep -v '^#' .env | xargs)

terraform apply \
  -var="apprunner_connection_arn=$APPRUNNER_CONNECTION_ARN" \
  -var="vpc_connector_arn=$VPC_CONNECTOR_ARN" \
  -var="env_prod_db_username=$PROD_DB_USERNAME" \
  -var="env_prod_db_password=$PROD_DB_PASSWORD" \
  -var="env_prod_fe_url=$PROD_FRONTEND_URL" \
  # any other environment variables your API needs

After successful deployment, you should see a success message in the terminal with the following outputs:

api_service_url = “«value»“
api_service_arn = “«value»”
api_service_status = “«value»“

[Optional] Service Update

For updates to the service, you can use sh update.sh:

#!/bin/bash

export $(grep -v '^#' ../.env | xargs)

API_SERVICE_ARN=$(terraform output -raw api_service_arn)

# Updates the App Runner service with the configuration in the input.json file
aws apprunner update-service --service-arn $API_SERVICE_ARN \
    --cli-input-json file://input.json

echo "App Runner service has been updated"

However, the input.json file needed for the script needs to contain the JSON version of the entire service configuration (which seems like a pain tbh).

Is there a way to use a script similar to the above to update the service with the configuration updates only?🤔

Possible Issues You Might Encounter

If you have existing app runner connections and VPC connectors, ensure they are in the new region you are deploying to; these resources need to be located in the same region (your terraform script will throw an error otherwise).
After successful deployment, I ran into a database connection timeout error. However, this was related to the error shared in my previous post and I resolved it by allowing inbound access to the database via the security group of the app runner service.

Thanks for reading, and I hope you find it useful!

P.S If you have any suggestions on updating the service without rewriting the entire setup configurations, please let me know in the comments.

Migrate Your Local MySQL Database to AWS RDS

Airat Yusuff — Thu, 12 Sep 2024 11:00:00 +0000

In this post, I'll share detailed steps to migrate data in your local MySQL database to newly created instances on AWS RDS with MySQL.

Background

I worked on a full-stack project in 2023 where I manually handled the production deployments of my database and backend to AWS. Earlier this year, I shut down all infrastructure because I was accumulating too much monthly costs with the database (no thanks to me overprovisioning).

Now, fast forward to this month and I still had lots of AWS credits (perks of being a Community Builder) due to expire by the end of the year. I tried to get my project back up only to realise it would not be as easy as I thought.

First, I had not properly created a snapshot that I could use to restore the production data and kept getting access errors. I was also reminded of how excruciatingly manual the entire deployment had been, and how I did not document any of the steps I took (neither did I remember them).

That was a lesson learnt, so this time, I am documenting the entire process. In line with one of the sayings in an Udemy course I never finished:

'You have to know to perform a task manually before proceeding to automate it'.

Hence, I'll first share the steps I took to carry out the migration manually, and in a following post, I'll write scripts to provision the infrastructure with Terraform and also dump the local data into the remote db after successful launch.

This is also part of my self-assigned ongoing project to learn more about CI/CD by building a pipeline to automate the entire deployment of the project.

A) Manual Steps

1. Create a new DB instance on Amazon RDS

This time, I was more intentional and practical with the configuration. Although it was a 'production deployment', I still opted for what's likely the cheapest running costs since it's not an actual live product (this also influenced some security options I chose not to add).

I have summarised the options I chose in the 'Create Database' wizard below:



AWS Region: eu-west-2
Database creation method: Standard Create
Engine type/edition/version: MySQL/MySQL Community/MySQL 8.0.35
Use case template: Free Tier
Credential settings: define these as you'd prefer
DB instance class: db.t3.micro
Storage: gp2, 20GB, auto-scaling enabled up to 100GB
Connectivity: 
    - define these for your specific use-case; I chose not to use an EC2
    - Public access: Yes, because I wanted to connect to the database locally via MySQL Workbench
Database authentication: Password auth
Additional configuration:
    - I created one database from here; but you can also leave it blank and create one when you get access via Workbench
Others: 
    - use default options or modify for your use-case
Deletion protection:
    - enabled (to dissuade myself from deleting easily like the last time)

Estimated monthly costs:

2. Connect to the RDS instance locally

After the instance has successfully launched, use mysql client to connect to the instance. This assumes you have your MySQL server installed and running.

Getting started with MySQL
MySQL client

You will also need the instance endpoint, and the username and password you defined in the credentials settings, to run this command:



mysql -h sample_endpoint.rds.amazonaws.com -u username_sample -p

Note: Your instance would have been created with the correct inbound and outbound rules for the selected VPC security groups.

However, if you run into errors connecting, confirm that your IP address is included in the allowed source for the inbound rules. I encountered a similar issue when I created the instance in a specific location with its IP address, and when I tried to connect with a different IP address in another location, the connection timed out.

[Optional] Create your database
If you skipped the Additional configuration step during the instance creation, you can create one at this step:



CREATE DATABASE sample_db;

3. Import data from your local database

To do this, you first need to use the mysqldump command to export the schema and data in your local db to a .sql dump file:



mysqldump -u root -p local_db_name > sample_dump.sql

Note: If you run into errors while trying to export, check out my question on Stack Overflow and also an answer that could resolve some possible issues.

Afterwards, use the mysql command to import the dump file to your RDS instance:



mysql -h sample_endpoint.rds.amazonaws.com -u username_sample -p 

sample_db < sample_dump.sql

[Optional] Connect to your RDS instance via MySQL Workbench

Confirm that you are able to connect to the instance without issues, and check the schema and data inside the database to confirm that they were also imported correctly.

Unable to connect?

Ensure you have correctly configured the public access settings, or
Use an EC2 instance to securely connect to the database and run your sql commands through the instance. Ensure that the EC2 instance is also inside the VPC where the RDS instance is located.

Next up will be:

deploying to App Runner with the required database credentials from this post (and necessary infrastructure access),
scripting with Terraform instead, and
creating a CI/CD pipeline to update future backend and frontend updates.

AWS CDK For Noobs: Deploying NextJS Apps

Airat Yusuff — Wed, 24 Jan 2024 08:41:22 +0000

As a software developer, have you ever wanted to deploy your personal projects to AWS instead of PaaS providers like Netlify or Heroku, but do not want to go through setting up everything manually through the AWS console or learning to write infrastructure-as-code?

Then, you are the target audience for AWS Cloud Development Kit (CDK).

This post is part of my commitment to Women Who Code Days of Code challenge✨

What is AWS CDK?

It is an AWS development framework for provisioning cloud infrastructure using programming languages familiar to software developers.

Simply put, it's a tool for software developers to deploy their apps onto AWS without manually setting up resources through the console, or writing declarative/imperative infrastructure-as-code.

In this post, I'll share all about my first experience with CDK and how I eventually deployed the most basic NextJS app.

First Attempt

I first tried it last month by starting with the free AWS CDK Primer course on Skills Builder; however, the course mostly covered the theory basics and a broad overview of how it may be used. There was not much insights on how it could be used for practical projects e.g deploying a full-stack app (which is understandable, since it was a free primer course).

Then, I tried using the learning path on Cloud Academy but it quickly became disengaging since the contents were focused on Python (hence a different version of the API docs) and I preferred Typescript. Overall, I found myself quite lost, trying to figure out the "right" thing to do according to the docs, and if there was only one way to do it. Meanwhile, every other tutorial (even the basic ones) seemed to already know their way around navigating the necessary construct libraries.

I eventually tried this tutorial to get something done (at least) and was able to deploy a basic NextJS app.

How to set up a CDK app for deploying a NextJS app to AWS Amplify

This assumes you have:

installed the AWS CDK toolkit,
installed Typescript (somehow, this was my first time doing this!),
configured your AWS credentials, and
generated a GitHub PAT and saved to AWS secrets manager.

If necessary, watch the linked tutorial for all preliminary setup.

1) Create an empty folder (e.g cdk-next-app) and set up a CDK app

cdk init app --language typescript

The 'app' template sets up a basic CDK app in language Typescript.

2) Set up your preferred environment in `bin/cdk-next-app.ts`

This is optional but I personally think it might be best to specify and avoid the 'environment agnostic' situation.

COPY

COPY
import * as cdk from 'aws-cdk-lib';
import { CdkNextAppStack } from '../lib/cdk-next-app-stack';

const app = new cdk.App();
new CdkNextAppStack(app, 'CdkNextAppStack', {
  env: { account: process.env.CDK_DEFAULT_ACCOUNT, region: process.env.CDK_DEFAULT_REGION },
});

This creates your CDK app and within it, a stack which will have all of the constructs needed to provision infrastructure for the Next app and deploy it to AWS Amplify.

Check out the Primer course for AWS CDK basics.

3) Set up the stack in `lib/cdk-next-app-stack.ts`

Note: This uses @aws-cdk/aws-amplify-alpha, which is basically the construct library with experimental features for Amplify using CDK. The current stable version does not have L2 constructs (constructs for provisioning AWS resources) yet, so the option was either the experimental library or setting everything up using L1 constructs (which I would have to look into👀).

Comments have been added to briefly explain the codes.

COPY

COPY
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import {
  App,
  GitHubSourceCodeProvider,
  Platform,
  RedirectStatus
} from "@aws-cdk/aws-amplify-alpha";
import * as codebuild from 'aws-cdk-lib/aws-codebuild';

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

    //create a new Amplify app
    const amplifyApp = new App(this, 'NextApp', {
      //set a code source provider for the app to be deployed e.g GitHub
      sourceCodeProvider: new GitHubSourceCodeProvider({
        //requires all three properties
        owner: 'khairahscorner',
        repository: 'sample-next-app',
        oauthToken: cdk.SecretValue.secretsManager('github-token-cdk'),
      }),
      autoBranchDeletion: true,
      platform: Platform.WEB_COMPUTE, //required for SSR apps 
      customRules: [{ //used to avoid page errors by redirecting them
        source: '/<*>',
        target: '/index.html',
        status: RedirectStatus.NOT_FOUND_REWRITE
      }],
      buildSpec: codebuild.BuildSpec.fromObjectToYaml({
          // Alternatively add a `amplify.yml` to the repo
          version: '1.0',
          frontend: {
            phases: {
              preBuild: {
                commands: ['npm ci'],
              },
              build: {
                commands: ['npm run build'],
              },
            },
            artifacts: {
              baseDirectory: '.next',
              files: ['**/*'],
            },
            // save time on npm reinstalling??
            cache: {
              paths: ['node_modules/**/*'],
            }
          }
      }),
    })

    // branch to deploy
    let branchName = 'main';
    amplifyApp.addBranch(branchName)

    //outputs the url to both your console and Outputs in the CF stack
    new cdk.CfnOutput(this, 'AmplifyAppUrl', {
      value: `https://${branchName}.${amplifyApp.appId}.amplifyapp.com`,
      description: 'Amplify App URL',
    });
    }
}

4) (Optional) Run `cdk bootstrap` and `cdk synth`

cdk bootstrap is used to setup necessary resources required to store and manage the deployment artifacts for your CDK app. Run this if it's your first time using AWS CDK, else it uses the existing setup on your AWS account.

cdk synth generates the AWS CloudFormation template version of your code, just to have a look through.

5) Deploy your app with `cdk deploy`

That's it!

Pitfalls to Avoid

1) Ensure you have installed and authorised the AWS Amplify GitHub App.

I previously installed and authorised it for only one repository, so I encountered a permissions error and eventually fixed it by authorising the current repository.

2) AWS Amplify seems to run with node v16 (with support up to v18.13).

However, Next14 requires a minimum of node v18.17, hence I was getting this error despite trying different fixes.

In the end, I downgraded to next13 and it worked, but do let me know if you know of a workaround for next14.

Up Next

I'll be trying more sample app deployments with CDK and maybe even explore CDK for Terraform.

Thanks for reading!

Generative AI For Noobs: Learn With AWS PartyRock!

Airat Yusuff — Thu, 16 Nov 2023 20:44:15 +0000

Whether you work in tech or are relatively new to the ecosystem, Generative AI is a buzzword you have most likely come across, especially with tools with ChatGPT. You may not even understand what it is about but now you can!

AWS PartyRock just launched and I personally think it's a great way for anyone (literally) to learn more about generative AI and AI-powered apps in general. In this post, I share how I used PartyRock to build an app for one of my hobbies: curating skincare routines!

The app I built.

But first,

What is AWS PartyRock?

PartyRock, an Amazon Bedrock Playground

PartyRock is a playground for building generative AI-powered apps, ZERO coding involved. With PartyRock, you can build your own AI app within minutes and share it with the world!

This was me 2 days ago!

All you have to do is describe what you want to build as your app, and PartyRock does the rest.

Being a playground, you get to learn the fundamentals of generative AI in a fun way by building silly (or not-so-silly) apps and experimenting hands-on with prompt engineering.

Note: This is not a guide to learn about Generative AI or prompt engineering, so I'll just include links to resources on them if you want to learn more.

Prompt Engineering on AWS

What is Generative AI?

How to Get Started With PartyRock

1. Visit the website and sign up for an account.
You can use your Google, Apple or Amazon account.

No, this account is not related to your AWS account, if you have one.

P.S. I really like the UI! It gives off a playful feel (which is spot-on for its purpose).

2. Once your account is created, simply get started! You can either:

click on the Build button on the home page,
Scroll to the bottom and describe your app with 'Let's Build', or
Or go to 'My Apps' and click to generate your new app.

You can also remix any of the listed apps if you do not want to start from scratch.

3. Describe your app in 2-3 sentences (or as many details as you can). For mine, I gave some context and what I wanted the app to do.

This gets you started on practising prompt engineering.

Voila! Your app is ready to go!

4. (Optional) Tweak your app

There are several ways to make your app better.

First, you can try resizing the widgets to get a better layout. This was my final layout after resizing and moving the widgets around.

You can also add new widgets and edit existing widgets. There are different kinds of widgets as shown below.

And most importantly, you can edit the AI-powered widgets (the ones that show the results of your app) to improve your prompt engineering skills.

I modified mine to include more details and be more specific with some parts of the responses.

Before:

After

The Result

I also played around with the models and it was interesting to see how they all presented different responses for the part of the prompts that had to do with text formatting.

E.g., Claude Instant sometimes presented the links the way you’d expect (as shown below) but other times it did not. Claude almost always presented links plainly and the Jurassic models ignored all text formatting prompts.

Claude

Jurassic-2 Mid

And that gives a summary of what you can do with PartyRock.

Check out my app here!

Now, it's your turn!

Try building yourself an app that does anything you can imagine - it could be a daily motivational quotes app or any other random idea you have!

A Question About PartyRock

1) No, PartyRock is not an AWS "product". It is simply a playground for you to learn more about generative AI and work on your prompt engineering skills.

What better way to do that than to learn hands-on by building apps?

However, it is powered by the foundational models available on Amazon Bedrock, so you also get to use some of these models and observe how they work before moving over to utilise them in Bedrock.

To learn more about PartyRock and how to use it, check out the following resources:

Thank you for reading and I hope it was a fun one for you.

Like PartyRock says, anyone can build AI apps so, happy building!🎉

Deploying Node.js Apps on AWS: Elastic Beanstalk Or App Runner?

Airat Yusuff — Wed, 25 Oct 2023 09:24:55 +0000

AWS offers over 200 services, with each of them catering to different use cases. There are at least 5 of them for deploying web applications and API services, so it can be difficult to decide which service is best suited for your use case.

I recently tried to build an API using Node.js and I wanted to deploy using AWS Elastic Beanstalk - it is often the recommended choice for deploying Node.js applications and I was also familiar with it.
However, I soon realised that it was not the best choice for my application and had to find an alternative, which led me to App Runner.

Although App Runner was more suited for my use case, time and effort were already wasted, so I decided to write this article to possibly prevent you (and future me!) from dealing with the same scenario.

This post contains a brief overview of the API, how it was deployed to AWS Elastic Beanstalk, the issues encountered that led to using App Runner, and how it was successfully deployed. It wraps up with a summary of how to choose the better option for your use case.

This AWS article on choosing the right container service is also a good place to start when making this decision. Both App Runner and Elastic Beanstalk are provisioning services, so they handle the orchestration layer complexities and are optimised for ease of use.

Background

The API was built using Express.js and integrated with a MySQL database using Sequelize. This meant I needed to deploy both the database and API, which was not a problem.

First, I created a database on AWS RDS using the MySQL engine, added the credentials to connect to my API, switched to the production configuration, and synced the database.

Next was deploying the API.

AWS Elastic Beanstalk

Elastic Beanstalk is a fully managed service for deploying and managing web applications, with support for containers. I deployed to Beanstalk using the following steps:

For Elastic Beanstalk

Issues Encountered

1) Error connecting to the database

Although the deployment was successful, I kept getting "502 Bad Gateway" errors when accessing any endpoint. I checked the logs and it showed some ETIMEDOUT errors.

Fix: Create a security group with inbound rules for your database (in my case, MySQL) to allow traffic from the Beanstalk environment (via its security group) into the database.

The full solution can be found here.

This error also occurred with App Runner but the resolution required an extra step, as described later below.

2) Mixed Content errors

This was the main limitation that caused the switch.

As you might expect, the project was full-stack and the web app was deployed to Netlify, which deploys to HTTPS but Beanstalk primarily deploys applications to HTTP. This resulted in Mixed Content errors whenever a request was sent to the API from the front-end.

To resolve the issue, a custom domain is needed to configure the Beanstalk environment with HTTPS. However, since I did not want to purchase one, I attempted to use a load balancer, where the balancer terminates the HTTPS connection before getting to the instance and listens for the request on HTTPS with a self-signed certificate.

Resources used for the solution can be found at the bottom of this article.

The fix worked and I was able to get rid of the Mixed Content error. However, this flags the frontend connection as non-secure because the self-signed security certificate on the API is not trusted by Chrome.

It was at this point I decided to explore other services as I had already spent too much time creating a workaround for Beanstalk.

P.S. Initially, I deployed the web app to AWS Amplify but eventually switched to Netlify because, unlike Amplify, it allows editing of the URL of the deployed app without having to use a custom domain.

After doing some research and learning that App Runner deploys applications to HTTPS, I decided to use it instead.

AWS App Runner

App Runner is a fully managed service for deploying web applications and API services easily by connecting your source code, containerising and then deploying.

It offers the simplest approach to deploying these applications without having to manage the infrastructure.

Deploying with App Runner

Extra Fix for Issue Encountered with Database

When creating the service, under "Networking" configurations, configure the service to use "custom VPC" for outgoing traffic and create a new VPC Connector.

Note: Ensure that the security group previously created for database access is included in the security groups for the VPC Connector. It should be configured with the default security group for the custom VPC being used for the service or opened up for all IP addresses (not recommended).

Conclusions

Both services can be used to deploy Node.js APIs and each has its pros and cons.

Linking the article on choosing the right AWS container service again.

1) If you want the simplest approach, App Runner is the choice for you.

2) If you have a custom domain for your API, you can try Elastic Beanstalk. If not, App Runner is a better choice.

3) If your application does not need regular updates, Elastic Beanstalk is still good to go. However, if you regularly make updates to your application, App Runner is a more suited choice.

This is because new updates are deployed on Beanstalk by uploading the updated .zip version of the application and switching. As far as I know (please correct me if I'm wrong), this is how updates are typically made and the process is too manual in my opinion.

On the other hand, App Runner connects to a GitHub repository (or image registry) and can be configured for automatic redeployment when new updates are pushed to the repository.

Summary

Best for AWS Elastic Beanstalk
1) Custom domain available
2) App is not regularly updated.

Best for AWS App Runner
1) Simplest solution to use without any prior knowledge
2) no custom domain for API
3) app is regularly synced with new changes.

Thank you for reading and I hope you find it useful!

Convert AWS CloudFormation Template For a Highly Available Web Server To Terraform Script

Airat Yusuff — Tue, 31 Jan 2023 10:17:26 +0000

I tried out Terraform for the first time in one of my previous posts and since nothing beats learning by continuously doing, I decided to convert a CloudFormation script I wrote to "deploy infrastructure for highly available applications" to its Terraform version.

Remember this post? Yeah, the CloudFormation script from this project.
The project was mainly to understand (and practice) what to consider when deciding between high availability of applications vs. optimising costs, and how that translates to the architecture.

Prerequisites: Have Terraform Open Source installed.

Steps to Convert CloudFormation templates to Terraform scripts

There are three main steps after creating and writing the configurations but I'll be highlighting every other step as well.

Structure the folder

The project uses the modules/folder structure because real-world projects will typically be structured that way. I created sub-folders like setup, security, etc to create separate files with the configurations for each section.

As highlighted above, each folder had at least its main.tf, outputs.tf and variables.tf files.

Convert each resource declaration to terraform syntax

This is where I spent the most time; there are several resources provided by the Terraform team to learn about different aspects of the tool; language syntax, CLI commands, providers' documentation, etc. I also encountered several errors and got some clarifications from reading the documentation.

The final configuration files can be found in this repo.

Link to the CF template

And now to the "main" steps:

Initialise the working directory

The directory that contains the configuration files defined above must be "initialised" before Terraform commands can be used to perform any operation. This is done with terraform init and this pretty much sets up the folder with all the necessary configurations Terraform needs.

terraform plan and terraform apply

The plan command generates a preview of the updates to be made (this can be saved in .tfplan file.

P.S it can be saved in files other than the default tfplan but those require extra configurations that may be unnecessary.

One of the issues I encountered during this step was associating route tables with subnets. Unlike AWS CloudFormation where I had to create each subnet individually (hence having direct access to the individual subnet_id), Terraform provides meta-arguments like for_each that can be used to create similar subnets with just one configuration.

However, it becomes difficult to directly retrieve the subnet_ids and use them in another for_each for creating the matching route-table associations.

As suggested, a workaround would be to use the -target option to apply just the setup module before proceeding. This is not recommended as highlighted in the docs so I created the resources individually instead since the values I needed could not be defined statically beforehand. That did not seem efficient so there would most likely be another way.

Workaround #1:

terraform plan -out=tfplan -target=module.setup terraform apply tfplan -target=module.setup

Workaround #2:

Please let me know if you have another way of doing it!

Afterwards, run the commands as normal, and test:

terraform plan -out=tfplan terraform apply tfplan

Don't forget to delete your resources after you are done!

The command terraform destroy is the equivalent of deleting CloudFormation stacks.

The deployment can also be automated using a CI/CD tool so that's what I'd be trying out next!

Using ChatGPT to Deploy Backend APIs to AWS EKS

Airat Yusuff — Tue, 17 Jan 2023 18:34:08 +0000

If someone had told me to use ChatGPT to practice cloud projects at a faster pace or without feeling too much like a fraud, I would probably have dismissed it😅.

ChatGPT has been a hot topic for some time now so I decided to try it out as well. I had not fully grasped the concept of Kubernetes, and how AWS EKS was supposed to work, so I figured I could try the bot instead of the gazillion tutorials that just seem to confuse me more!

I asked ChatGPT (twice) for steps on how to deploy a full-stack app to AWS EKS and I got slightly similar answers on both occasions.

The responses provided a base for me to start and I was able to learn more about Kubernetes; what namespaces were, services, deployments of pods to nodes, etc.

In the end, I was able to work on a project that deploys three containerised apps into one EKS cluster: two in the same pod, and one in a different pod; both in one node group with worker nodes.

I deployed to Minikube first and although it took me hours of reading and understanding different aspects (and debugging!), both versions eventually worked.

Steps to Deploy Three Apps (Flask, Node and Go) to Minikube and AWS EKS clusters

I had already worked on the Dockerfiles for all three apps (using tutorials😅) and tested that they worked as expected using docker run and docker-compose up (for the two apps going into one pod).

I also built and pushed their latest Docker images to my repository, so these steps focus on how to deploy them to Minikube and AWS EKS.

These steps assume you have:

installed minikube, kubectl,
images pushed to Docker Hub and Docker desktop running, and
installed and configured aws-cli.

1) Deploy to Minikube

Start the Minikube cluster minikube start
Create a deployment either using kubectl create deployment or a manifest file

apiVersion: apps/v1 kind: Deployment metadata: name: sample-name-deploy spec: replicas: 1 selector: matchLabels: app: sample-name template: metadata: labels: app: sample-name spec: containers: - name: go-app image: [image from repo] - name: node-app image: [image from repo]
Running this file with kubectl creates a deployment which launches 1 sample-name pod (replicas field is optional if you want only one pod and no replicas).

kubectl apply -f deployment.yml

Create a service, also either using kubectl create or a manifest file

apiVersion: v1 kind: Service metadata: name: sample-service spec: type: NodePort selector: app: sample-name ports: - name: node-api protocol: TCP port: 80 #nodePort defaults to this value since it's undefined targetPort: 3000 - name: go-api protocol: TCP port: 9090 #nodePort defaults to this value targetPort: 8080

Here, I'm using ports 3000 and 8080 as the ports for the service to listen for requests and pass to the appropriate container in the pod(s) created by the sample-name-deploy deployment.

kubectl apply -f service.yml

Check whether the pod(s) successfully started and get the name(s), and run either of the containers(apps).

kubectl get pods kubectl port-forward pod/[pod_name_here] --address 0.0.0.0 3000:3000

You can also run the script below to run the apps in the browser using port forwarding (if you launched one pod):

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}') echo Name of Pod(s): $POD_NAME kubectl port-forward pod/$POD_NAME --address 0.0.0.0 3000:3000 kubectl port-forward pod/$POD_NAME --address 0.0.0.0 8080:8080

The app(s) should be running on their respective ports.
The service can also be created as a LoadBalancer type to access the apps via an external IP.
apiVersion: v1 kind: Service metadata: name: sample-service spec: type: LoadBalancer ...
However, to use this type for Minikube, a tunnel must be started to get access to an external IP for the service (else, it just shows as pending when you run kubectl get svc).
kubectl tunnel

Deploy to AWS EKS

Steps 2 and 3 remain the same but an EKS cluster (with at least one node group for worker nodes) must be created.

Create an EKS Cluster and node groups on the console (or use a .yaml file)
You would need to have/create an IAM role to grant access to the Kubernetes control plane (aka EKS) to manage AWS resources; the same for the node groups.
Configure kubectl to communicate with the cluster

aws eks update-kubeconfig --name [cluster-name]

Run steps 2 - 4; using port forwarding for the cluster also worked.

As mentioned earlier, you can create the service as a LoadBalancer to run the apps via an external IP. However, for AWS, this creates the legacy classic load balancer so I tried to find out how to use one of the current load balancer types instead.

The steps to use an Application Load Balancer is more involved:

Follow the steps here to create AWS Load Balancer Controller. It was a very long process for me because I used kubectl, so you might want to try eksctl instead.
I also had to ensure my subnets were tagged as specified in the guide to allow the load balancer "automatically pick up" resources it should pick up (and all the other requirements listed in the guide). After setting up the controller, you can create the ingress resource itself with this guide.
I ran into quite several issues and could not get it working as expected, so I plan to come back to this later.

There you have it!

I was able to successfully deploy all three apps. I still have pending issues to resolve with using an ALB instead of the default LB created by Kubernetes, but I'm positive I will find the solution soon!

DEV Community: Airat Yusuff

Monitoring Java APIs with Amazon CloudWatch and AWS X-Ray

Project Overview

Architecture

Setup

Pre-Requisites

1) AWS Setup

2) Configure Instance

3) Deployed App

X-Ray Traces

CloudWatch Logs

Troubleshooting

Conclusion

Leveraging Lambda Functions (with Amazon SNS, S3 & EventBridge)

Project Summary

Architecture

Build Process

Repo structure:

Gotchas

S3 Event Notifications

Conclusions

Deploying Scalable APIs With Terraform and GitHub Actions

Project Summary

Main Concepts Covered

Architecture

Repo Structure

Infrastructure Configuration

Step 1: AWS Environment Setup

Step 2: ECS Setup

Continuous Deployment

Workflow Structure

Debugging Issues

Conclusions

Build and Deploy Streamlit (Python) App on AWS ECS with Fargate

Concepts Covered

App Features

1) Building and Running the App Locally

2) Running as a Container

3) Deploying to AWS

Enhancements

State Management in React Using MobX State Tree (MST)

Brief Overview: What even is MobX-State-Tree?

Why Try It?

Why You Probably May Not Like It

Summary

Automate Deployment to AWS App Runner Using Terraform

Prerequisites

Setup

[Optional] Service Update

Possible Issues You Might Encounter

Migrate Your Local MySQL Database to AWS RDS

Background

A) Manual Steps

1. Create a new DB instance on Amazon RDS

2. Connect to the RDS instance locally

3. Import data from your local database

[Optional] Connect to your RDS instance via MySQL Workbench

Unable to connect?

AWS CDK For Noobs: Deploying NextJS Apps

What is AWS CDK?

First Attempt

How to set up a CDK app for deploying a NextJS app to AWS Amplify

1) Create an empty folder (e.g cdk-next-app) and set up a CDK app

2) Set up your preferred environment in bin/cdk-next-app.ts

3) Set up the stack in lib/cdk-next-app-stack.ts

4) (Optional) Run cdk bootstrap and cdk synth

5) Deploy your app with cdk deploy

Pitfalls to Avoid

1) Ensure you have installed and authorised the AWS Amplify GitHub App.

2) AWS Amplify seems to run with node v16 (with support up to v18.13).

Up Next

Generative AI For Noobs: Learn With AWS PartyRock!

What is AWS PartyRock?

How to Get Started With PartyRock

A Question About PartyRock

Deploying Node.js Apps on AWS: Elastic Beanstalk Or App Runner?

Background

AWS Elastic Beanstalk

Issues Encountered

AWS App Runner

2) Set up your preferred environment in `bin/cdk-next-app.ts`

3) Set up the stack in `lib/cdk-next-app-stack.ts`

4) (Optional) Run `cdk bootstrap` and `cdk synth`

5) Deploy your app with `cdk deploy`