DEV Community: Tambe Salome

Contributing to OCaml-Tiff So Far - Writing TIFF Files

Tambe Salome — Tue, 24 Feb 2026 13:26:20 +0000

I have been working with OCaml and contributing to the OCaml TIFF library since the 8th of December, 2025. While applying for the internship, I submitted what we envisaged as a timeline to complete the project at hand. My proposed timeline looked like this:

Week 1-4 Orientation and Setup: Learning OCaml concepts using the Real World OCaml book, having a walkthrough on the project, and learning more about geospatial data and how it's managed in TIFF files.
Week 5-6: Refactoring the code into low-level and high-level libraries
Week 7-8: Building in cache support to enable writing TIFF files
Week 9-10: Add advanced support for Geospatial data
Week 11-12: Continuous work on the project, especially if goals were not attained during the internship scope

When I came up with this seemingly perfect plan to contribute to this project, I didn't yet have a full grasp of what I needed to know. So, over time, I had to adjust my approach to meet the project's goals.

How it all played out

As per the original plan, I spent the first few weeks learning OCaml by reading the Real World OCaml book and the OCaml Programming textbook. To avoid getting stuck in a cycle of continuous learning and reading, my mentor, Patrick Ferris, recommended that I go through the project and just read code while learning.

As someone new to the programming language, it might be difficult to understand anything at first, but the goal in itself is not to understand the entire project, but to become a little more familiar with how data flows and is manipulated throughout the project.

Getting familiar with the project

A good place to start when working on a new project is with the test files, and that is what I did.
The project's benchmark tests were initially used to measure the runtime of functions that read TIFF files using the Unix library, an interface to the Unix file system; however, the project also utilizes OCaml's Eio library. The Eio library is better suited for concurrent programs, and it provides a higher-level, cross-platform API. Since we used two backends, I updated the benchmark tests to compare the runtimes when reading the TIFF files with the Unix and Eio backends; PR: Add support for eio library.
Currently, the only way to know the contents of a TIFF file after reading it with the OCaml tiff library is through the tests. To effectively write and add new tests for the TIFF files, I used Python's tifffile library to generate TIFF files with specific features and then wrote new tests that assert that those values are read correctly by the ocaml-tiff library. The next step was to make sure ocaml-tiff interoperates with Raven. Raven provides OCaml with scientific computing capabilities and makes it easy to manipulate data. I swapped out the use of the owl-base library for Raven's Nx library in the test [PR: Change the use of owl-base to nx in tests].
The pluggable backends in Nx allow implementation for different hardware. It also provides better performance compared to Owl and is an equivalent of Python's Numpy. Reading the documentation for the various libraries helped me understand how they worked better and guided me on what to implement. I also found the OCaml Discourse forum very useful for finding answers to my questions.

Writing a TIFF File

TIFF is a tag-based file format for storing and interchanging raster images. Digital images come in two formats, raster and vector. Raster images are produced when scanning or photographing an object and are generally what you think about when you think of images.
To effectively write a TIFF file, it is important to understand the file structure. I read through the TIFF specification docs to get familiar with the different parts of the TIFF file, the kind of data stored in it, and what each part means.

The approach I used to write a TIFF file was to first successfully use an existing TIFF file to create a new one.

The first part of a TIFF file is the Image File Header.

Bytes 0-1: a string that specifies the file's byte order: "II" for little-endian and "MM" for big-endian.
A magic number used to identify the file as a TIFF file. 42 is used for a normal TIFF file, and 43 for Big TIFFs. If the file is a Big TIFF file, this value will occupy 6 bytes; otherwise, 2 bytes.
The offset for the first Image File Directory(IFD), that is, the location in the file where the IFD is found, is the last thing stored in the header. 8 bytes are used in a Big TIFF, and 4 bytes for a simple TIFF.

In the File module, I added a new definition for the writer, File.wo, similar to that used for reading the TIFF.

type wo = file_offset:Optint.Int63.t -> Cstruct.t list -> unit

The definition specifies that to write to a file, the user needs to pass the file offset, that is, the location in the file at which the writing is to start, and a buffer containing the data to be written at that location.

Since the header is the first thing in the file, its offset is always zero. So, to write the header, I determined all the data that had to be stored in the header, stored it in a buffer, and then wrote that buffer to the file at offset=0.

let write_header wo header =
  let buf = Cstruct.create 16 in

  Cstruct.blit_from_string
    (match header.byte_order with Endian.Little -> "II" | Endian.Big -> "MM")
    0 buf 0 2;

  (match header.kind with
  | Tiff ->
      Endian.set_uint16 ~offset:2 header.byte_order buf 42;
      Endian.set_uint32 ~offset:4 header.byte_order buf
        (header.offset |> Optint.Int63.to_int32)
  | Bigtiff ->
      Endian.set_uint16 ~offset:2 header.byte_order buf 43;
      Endian.set_uint64 ~offset:8 header.byte_order buf
        (header.offset |> Optint.Int63.to_int64));

  wo ~file_offset:Optint.Int63.zero [ buf ]

I also defined functions in the Unix and Eio module that'll be used for writing. Since ocaml-tiff uses Unix and an Eio backend, defining File.wo provides an easy struct required by the various backends.

TIFF files are tag-based, and an IFD entry is used to store those tags and their values. The entry contains:

Tag: A unique number used to identify the entry
Field: A number indicating the datatype of the entry's value
Count: Number of values in the entry
Value/offset: Can contain the actual data if it is less than 4 bytes for a TIFF and 8 bytes for a Big TIFF. If the data is larger, it'll contain its location in the file instead. Possible values for the entry tag and field are found in the TIFF specs.

At this stage, I was using the IFD entries read from one file to write to the new file. Writing an entry whose value was not immediately stored in its IFD entry was quite challenging when copying the IFD to the new file. In such cases, I had to write the entry, then read the entry's data at the offset specified in the entry and write it to the file at that offset. It doesn't sound as complicated now, but it was a hassle when I was trying to figure it out :)

IFD entries are separate from the actual image data. The data is stored in strips, and an important IFD entry is the StripOffset, which contains the various locations of the strips of data. The image data must not come immediately after the IFD entries, so the offset values are used to read and write the data accurately. The StripByteCount is also used to determine the length of a strip at an offset location.

I used the same idea I described for writing the header to write the IFD entries and the image data to the file. The complete implementation for duplicating a TIFF file can be seen in this PR

The final step is to be able to make a TIFF file from scratch, which will be the discussion for the next post.

Important to Note - Gotcha Moments

Most times, the StripOffset value would not fit into an IFD entry since it's larger than the required size. At first, I thought writing the values of strip offsets meant writing the image data; however, it's just the location of the actual image data. That means writing the StripOffset entry actually means writing at an offset the offsets of data😂
Optional arguments are best put in front; Never put your optional arguments at the end.
Endianness specifies the byte order in the file; least significant byte to the most significant byte for little-endian, and most significant byte to least significant byte for big-endian. The file is either a Big TIFF file or a TIFF file, depending on the magic number in the header and not on the endian values.

About Me - An Outreachy Blog

Tambe Salome — Mon, 22 Dec 2025 13:06:45 +0000

Hi, I am Tambe Salome, and I am an Outreachy Intern! In this blog, I will be talking about my journey as a software developer and how I found myself as an Outreachy intern in the OCaml organization.

Brief Introduction

Again, I am Tambe (tam-bear) Salome. I am a 22-year-old girl from Buea, Cameroon, a country in Central Africa. I graduated from the University of Buea in 2024 with a Bachelor of Engineering in Computer Engineering. I like building secure software and contributing to tech communities. I have been a volunteer for the Google Developer Groups Buea since 2020.

Tambe the Explorer🔭

Outreachy Attempts

I first applied to be an Outreachy intern in 2021 when I just started learning how to code with C. I used the book C Programming: A Modern Approach and really loved it. It gave me solid programming foundations. I was accepted for the contribution phase, but quickly became overwhelmed by the available projects. This led me to be unable to make any contributions during this period.
I also didn't seek guidance early enough and was trying to figure everything out on my own.
I've applied to Outreachy almost every other year since then, but was never accepted for the contribution phase, until this year, when I was, and then I got in :)!

To Code or Not to Code

I started with the C programming language, but had difficulties finding where I could use it extensively to build really useful things. Almost all the projects I came across on GitHub that used C wrote a version that seemed very foreign to me😄. As a beginner, I could barely understand what was going on in the projects, not to mention where to start contributing. I later on explored web development with Laravel and then React. However, all I was exposed to was not really "exciting" for me. I felt like I wanted to do something different.

When they cut out our internet in about 2017, I have always fantasized about being a hacker and finding a way to restore it completely 😂. I think this was one of the things that led me to explore Cybersecurity.
I began my cybersecurity journey with tryhackme.com, and was later accepted into the CyberGirls Fellowship program, a rigorous one-year program designed to encourage women to enter the field of cybersecurity. I participated in the Vulnerability and Penetration Testing track, and although it was exciting, I didn't get to write a lot of code during this time. Also, because I was doing this while being in engineering school, I had little time to work on personal projects that would have me writing code.

This made me realise that I would not just like to test the security of systems but also be actively involved in building those secure systems. Day-by-day, I am discovering more of what this means to me.

Community

I have always loved the idea of contributing to tech communities. It's been fulfilling to see people discover other possibilities or start a career in tech because of an event that I contributed in organizing. Most times, it feels like being part of a cause that is bigger than myself. I haven't figured out a lot, and seeing people figure out even what remains a mystery to me, because I was able to bring together a group of people to have a workshop or give a couple of talks, is extremely satisfying.

At GDG Buea, our motto is: A Community that Codes, and I'm very much interested in contributing to building a community of practitioners who build software at a global standard.

Discovering OCaml

Before this internship, all I knew about functional programming was probably only what was briefly mentioned in a course at school where we talked about programming paradigms.
Despite not knowing any OCaml before, I randomly picked a project in the OCaml organization because the project's chats were not already saturated with people wanting to contribute, so I thought this would increase my chances of getting in.
Unlike the last time that I got accepted into the contribution phase, I actually sought guidance and support from Day 1 after being selected this time. I was constantly reminded to ask questions in the channels whenever I got stuck and to share my progress on the tasks I was assigned.
I am contributing to an OCaml Library for reading and writing tiff files, and it sounded all so exciting and somewhat scary from the start. The project description mentioned extending the library's support for GeoTiff files, which store geospatial data, just what an explorer will like😄.
I read and re-read the existing code, and started learning OCaml with the Real World OCaml book. Picked an issue, worked on it, got blocked, got unblocked by mentors, made pull requests, and now I'm here interning in the OCaml organization, contributing directly to a library, and working with some of the best engineers.

What Now

I am continuously learning OCaml while making contributions to the tiff library with the help of my amazing mentor, Patrick Ferris. I put in maximum effort each day to work towards the project's goal of the library being able to write TIFF files.

One of my favorite talks is by Olumide Balogun, who constantly reminds me about Doing Hard Things, which I remind myself about each time I get stuck.

I look forward to working extensively with OCaml, working closely with other OCaml developers, and contributing to the mission of making OCaml mainstream.

Common Security Vulnerabilities in Dockerfiles

Tambe Salome — Thu, 14 Dec 2023 17:00:43 +0000

According to Docker Docs, a Dockerfile is a text document that contains all the instructions a user could call on the command line to assemble an image. These instructions include actions like installing software, copying files, setting environment variables, and defining how an application should run.

Wrongly implementing instructions in a Dockerfile might present vulnerabilities which attackers can exploit to gain root access to the underlying infrastructure, gain privileges by using exposed secrets, and so much more.

I have compile a list of common docker security issues using yaml. For each issue, I defined a regex rule which can be used statically analyze your dockerfile.
There are some limitations to using regex rules for static analysis, some of which include:

Dockerfile syntax may evolve over time causing the current regex patterns to become outdated.
Regex may not interprete the intended purpose of certain instructions.
Regex patterns may struggle in understanding multiline and nested instructions found in Dockerfiles.
They may lead to false positives or false negatives.

You can find the .yaml rules in this repository. I will appreciate your feedback and contributions.

Common Security Issues

1. Using the 'latest' tag for base images.

It is advicable to pin your docker image to a particular version instead of using the 'latest' tag which results to a different version at different points in time.

Using the latest tag doesn't gaurantee that you are using the most recent and stable version of an image. However, it might introduce breaking changes in the best worst case scenario or even security vulnerabilities in the worst worst case.

Always pin your images and dependencies to particular versions and update them regularly.

2. Running as Root

Secure system design follows the principle of least privilege. This simply states that a process should be able to access only the information and resources it needs to accomplish its legitimate purpose and nothing more.

Running processes as root in a Dockerfile can give access to code or other users to maliciously to gain full access to your container and host system. Not defining a user at all can also lead to unexpected behaviour that can lead to granting root access to non-root users or code.

To avoid this, always define a non-root user in your dockerfile that will be used to execute commands. This is done using the USER directive in your dockerfile.

3. Using Sudo to execute commands

Just as you shouldn't use the root user, you shouldn't use sudo to run commands either as it also violates the principle of least privilege.

When running as a user, also ensure the user is not in the sudoers file to avoid the complications that come from running as root.

4. Copying Unnecessary Files

Unnecessary files in your docker image can increase the size, complexity, and attack surface of your image. It can also slow down the build and run time of your docker container.

It is a Dockerfile best practice to create a subfolder that contains the files that need to be copied to the docker container image. Also, where possible, use a .dockerignore file to explicitly exclude files and directories. Avoid using wildcards like '.' when defining a COPY directive.

5. Exposed Secrets

Never store secrets or credentials in any form of docker instructions such as environment variables, args or hardcoded into any command.

You could make use of Docker Secrets to provide the values as environment variables.

6. Using Vulnerable Images

This kind of vulnerability is introduced from the hierarchy of layers used to build the container image. It provides a risk to supply chain attacks

Untrusted base images are the main source of such vulnerabilities and should be avoided at all cost. The source of the base image should be verified and the image should be updated regularly.

Common Security Vulnerabilities in Dockerfiles

Tambe Salome — Thu, 14 Dec 2023 17:00:43 +0000

Dockerfile syntax may evolve over time causing the current regex patterns to become outdated.
Regex may not interprete the intended purpose of certain instructions.
Regex patterns may struggle in understanding multiline and nested instructions found in Dockerfiles.
They may lead to false positives or false negatives.

You can find the .yaml rules in this repository. I will appreciate your feedback and contributions.

Common Security Issues

1. Using the 'latest' tag for base images.

It is advicable to pin your docker image to a particular version instead of using the 'latest' tag which results to a different version at different points in time.

Always pin your images and dependencies to particular versions and update them regularly.

2. Running as Root

To avoid this, always define a non-root user in your dockerfile that will be used to execute commands. This is done using the USER directive in your dockerfile.

3. Using Sudo to execute commands

Just as you shouldn't use the root user, you shouldn't use sudo to run commands either as it also violates the principle of least privilege.

When running as a user, also ensure the user is not in the sudoers file to avoid the complications that come from running as root.

4. Copying Unnecessary Files

Unnecessary files in your docker image can increase the size, complexity, and attack surface of your image. It can also slow down the build and run time of your docker container.

5. Exposed Secrets

Never store secrets or credentials in any form of docker instructions such as environment variables, args or hardcoded into any command.

You could make use of Docker Secrets to provide the values as environment variables.

6. Using Vulnerable Images

This kind of vulnerability is introduced from the hierarchy of layers used to build the container image. It provides a risk to supply chain attacks

Untrusted base images are the main source of such vulnerabilities and should be avoided at all cost. The source of the base image should be verified and the image should be updated regularly.

When Container Orchestration is an Overkill

Tambe Salome — Mon, 30 Oct 2023 15:42:55 +0000

Technology is becoming fascinating each day and the hype growing around concepts like container orchestration tools (e.g Kubernetes ☸️) keeps growing 📈. On one hand, these technologies are indeed amazing and companies are using them to better meet the needs of their users.

However, because of the hype around these technologies, a lot of companies both new and old are beginning to over-engineer their solutions, increasing the complexity of their products and focusing on how they have implemented these technologies instead of meeting the basic needs of their users 🤧 which can be done with simpler solutions.

This scenario can be likened to using an 🪓 axe to kill an 🐜 ant, which is totally not necessary. You can just step on it with your feet😂 (p.s. Don't kill ants, save the planet🌚)

This over-engineering can cause organizations to loose a lot of money, it can even deviate their attention from building solutions to setting up systems and overall, it will needlessly increase the complexity of the project.

One of such concepts that is continually being used recently to over-engineer solutions is container orchestration😕. In this article, we would look at what container orchestration is, and a brief history of how it came about🕰️. Then, we will then look at the benefits of using a container orchestration system, and finally when it can become an overkill.

What is Container Orchestration☸️?

Container orchestration automates the provisioning, deployment, networking, scaling, availability, and lifecycle management of containers. Some popular container orchestration tools are: Apache Mesos, Docker Swarm, and Kubernetes.

Application development in recent times has moved from a monolithic approach 💧 to using microservice 💦. Microservices are individual units of software that provide all of the functions required to run an application when combined together. Typically, each microservice handles a discrete type of functionality. An application can have separate services for image recognition🔴, authentication🟡, database🔵 and the UI⚪. Each of these would communicate using lightweight mechanisms like HTTP resource APIs to be interfaced as one application 🔴🟡🔵⚪.

Using containers📦, the architectural paradigm of using microservices can easily be implemented. Containers can be used to host the individual microservices that form an application. This means that a containerized application can translate into operating hundreds or thousands of containers, especially when building and operating large scale systems.

The complexity of this application increases if these containers are to be managed manually. However, with container orchestration, the complexity of managing containers is reduced as orchestration provides a declarative way of automating most of the work 🔁.

Benefits of Orchestration

Security:🔒 Container orchestration automated approach can help reduce the chance of human error, hence, keeping containerized applications secure. Also, because containers run in isolated environments, container orchestration tools can share only specific resources between users, reducing the risk of data breaches and other traditional security vulnerabilities.
Improved development:🏂 Orchestration allows teams to easily roll out and roll back versions or features with ease. This makes user needs to be met faster as the process of developement, testing, and delivering of software has become faster, repeatable and more efficient.
Cost Saving:💰 Container orchestration systems require less human effort enabling companies to save money by requiring less staff to build and manage systems. Also, orchestration systems maintains optimal usage of processing and memory resources, removing unnecessary overhead expenses.

When is Orchestration an Overkill?

overkill ( noun )
meaning: excessive use, treatment, or action.
example: "animators now face a dilemma of technology overkill"

For Small Startups 🤏

Setting up a container orchestration system might be too complex🤹‍♀️ and time-consuming⏱️ for these kind of teams. Setting up orchestration systems is a major project that might end up disrupting existing workflows.

For example, in the case of Kubernetes, worker nodes need to be configured with memory, disk speed, storage capacity and much more. Also, you would need to set up access control management and security for the kubernetes clusters and also configure the control plane. After completing the steps for setting up the kubernetes environment, they need to be regularly managed, maintained and monitored. This increases the complexity of the project and might deviate the team to concentrate on managing infrastructure instead of solving user problems.

Having Minimal Scalability Needs ⚖️

Orchestration might introduce unnecessary overhead for applications which have consistently low traffic or whose resource demands are predictable. When using orchestration tools for applications with low or predictable traffic, overheads can be incurred in terms of architectural decision and design when taking scalability into account.

Also, a part of the scalability planning phase is capacity planning which involves gathering data, performing calculations and making projections based on the data. The scalability of the system would then need to be tested and validated by building test setups, generating data for the test and performing analysis on the test results.

All of these steps would just end up lengthening the development time planning for scales that would not be met in a very long run.

Cost 💸

Container orchestration systems require more infrastructure, including servers, storage and networking. There is also additional cost incurred in managing and maintenance of these systems which includes time and resources needed to train the team and also salaries of skilled employees.

Although Kubernetes provides a way to ensure reliability and scalability of applications, it doesn't explicitly provide a way to measure and manage cost. Because of the dynamic nature of containers in the kubernetes environment it can become more complex to implement cost optimization as understanding the interplay between various components, configurations, and resource utilization patterns is needed.

Also, kubernetes operates at the infrastructure level making allocating cost to specific applications or workloads even more complex. Organisations would need to setup 3rd party applications in order to accomplish this.

Lastly, using a managed Kubernetes service such as Amazon's EKS, Azure Kubernetes Service or Google's Kubernetes Engin can come with with additional cost such as cluster management fees, control plane charges and other fees depending on the services provided by the cloud provider. These services are not really necessary for simple solutions like; a single-page application which has a database and cache. This types of applications can simply be deployed on a VPS. Container orchestration is best suited for applications running multiple microservices that need to communicate with one another.

Conclusion

As we have seen, there are benefits to using a container orchestration system. However, before deciding to use one, carefully consider if it is absolutely necessary. Do you really need it, or would it just be adding needless complexity and cost to your current workflow? Perhaps you can make you of a simpler solution.

Always remember that whatever you build is to satisfy the user first before considering how amazing you might feel from using popular tools 😂. I wish you the best in your development journey ❤️

Additional Resources

Thank you for reading through till the end😊. I hope it helped you in one way or the other to understand and use a particular concept. If you enjoyed reading this, do leave a like ❤️ and a comment stating how I can improve 💡

Overview of Containerization with Docker.

Tambe Salome — Tue, 24 Oct 2023 15:38:48 +0000

Introduction to Docker

According to Wikipedia, Docker is a set of platform as a service (PaaS) products that use OS-level virtualization to deliver software in packages called containers. Containers are lightweight and contain everything necessary to run an application, such that they become the unit for distribution and testing of applications.

Docker helps developers build, share, and run applications anywhere which significantly reduces the delay between writing code and running it in production.

Docker Images

An image is a read-only template with instructions for creating a container. Most times, an image is based on another image known as the Base image.
A Dockerfile contains the different steps to create an image and run it.
Images can also be downloaded from a public registry such as Docker Hub which is a cloud hosted registry that allows developers to share container images. Companies can also have their private repositories where they store container images.

Docker Containers

A container is a runnable instance of an image. It defines a way to package applications with all necessary dependencies and configurations. This makes the application easy to share. It also makes development and deployment more efficient.

Before containers, all services needed to be installed independently by each developer in the same team when working on the same application. The installation steps depended on the operating system each developer uses. There were also multiple steps used to complete this installation making the process was very error prone and tedious.

However, with containers, no installation needs to be done directly on the operating system because the container is an isolated system on its own with a Linux base OS. Containers are packaged with all the needed configurations for particular services and they need to only be pulled and used.

When a container is removed, any changes to its state that are not stored in a persistent storage disappear.

Benefits of Containerization

Portability: Containers encapsulate all configurations and dependencies needed to run an application which are abstracted away from the host operating system. This facilitates the portability of the container from one environment. Because of this ease in portability, agile processes can easily be implemented for rapid application development.

Scalability: Containers are light-weight, cheap, and can easily be launched. This makes it easier and faster to scale systems, and improve responsiveness and performance.

Security: Containers isolate the processes of one container from another, as well as from the host system. Thus invasion of malicious code in one container is inherently prevented from affecting others.

Security in Docker

When docker is used properly, it can increase the overall security posture of the application in comparison to running applications directly on the host. However, misconfigurations can lead downgrade the of security and even introduce new vulnerabilities.

Set resource quotas to limit the amount of memory and CPU resources that a container can consume. This feature helps prevent one application or container from using all system resources which can be used for a Denial of Service (DoS) attack.
Do not run as a root: Running docker as an unprivileged user ensures that if an attackers breaks out of a container, they will not have root privileges on the host, hence limiting the attack surface.
Secure the container registries: Container registries make it easy to set up a central repository from where container images can easily be pulled. The container registry you use should allow only particular users to upload or download from the registry.

💡 If you are interested in knowing more about docker security, you can check out this post on 21 Docker Security Best Practices - Daemon, Image & Container.

Automatically Provision AWS Resources with Terraform

Tambe Salome — Wed, 20 Sep 2023 16:59:13 +0000

Infrastructure as Code (IaC) provides a way of managing and provisioning infrastructure through code instead of manually. This helps improve infrastructure consistencies and increases speed for deployments as the same code can be used to provision multiple deployment environments.

Terraform is an infrastructure as code tool that lets you build, change, and version infrastructure safely and efficiently. It allows you monitor and build infrastructure for multiple cloud platforms.
Terraform plugins (providers) let you interact with cloud platforms and other services through their APIs.
A provider is a plugin that terraform uses to create and manage resources. You can view a list of providers offered by terraform providers here

Overview

In this tutorial, we would show how to automatically deploy an Amazon RDS MySQL instance, an ElastiCache Redis cluster and a Lambda function all in the same VPC with security group rules that enable the Lambda function to interact with the Redis cluster and the MySQL database. This deployment would be done using terraform.

Clone the Sample Repository

git clone git@github.com:giftcup/terraform.git

Then move into the lambda-serverless directory to view the sample code

cd lambda-serverless

Prerequisites

Terraform 0.14+ installed locally
An AWS account with credentials configured for Terraform

Verify you have terraform installed by running the following command in your terminal:

terraform version

Using the AWS Provider

The AWS provider allows you connect and interact with services and resources offered by AWS.
In our configuration, we will specify the provider and its version, the region, and the availability zones we want our resources to be deployed in

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# Configure AWS Provider
provider "aws" {
  region = "us-west-2"
}

data "aws_availability_zones" "available" {}

Create a VPC [Virtual Private Cloud]

Using the terraform-aws-vpc module, we create a VPC resource where we want all other resources to reside in

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.1.2"

  name                 = "second-vpc"
  cidr                 = "10.10.0.0/16"
  azs                  = data.aws_availability_zones.available.names
  public_subnets       = ["10.10.3.0/24", "10.10.4.0/24", "10.10.5.0/24"]
  enable_dns_hostnames = true
  enable_dns_support   = true
}

Add Security Group Rules

The security group rules here should enable us connect with the Elasticache Redis cluster and the RDS MySQL database from our Lambda function, all of which we will create later on.

You must specify the from_port and the to_port in the egress and ingress rules

resource "aws_security_group" "second-sg" {
  name   = "second-sg"
  vpc_id = module.vpc.vpc_id

  ingress {
    from_port   = 3306
    to_port     = 3306
    protocol    = "tcp"
    cidr_blocks = ["10.10.0.0/16"]
  }

  ingress {
    from_port   = 6379
    to_port     = 6379
    protocol    = "tcp"
    cidr_blocks = ["10.10.0.0/16"]
  }

  egress {
    from_port   = 3306
    to_port     = 3306
    protocol    = "tcp"
    cidr_blocks = ["10.10.0.0/16"]
  }

  egress {
    from_port   = 6379
    to_port     = 6379
    protocol    = "tcp"
    cidr_blocks = ["10.10.0.0/16"]
  }
}

Configure the RDS MySQL Database

Firstly define the subnet group that you would want your RDS instance to be in:

resource "aws_db_subnet_group" "second-subnet" {
  name       = "second"
  subnet_ids = module.vpc.public_subnets

  tags = {
    Name = "Second"
  }
}

The subnets specified here are the subnets that belong to the VPC above.

The database instance is created as shown below:

resource "aws_db_instance" "firsTerraDB" {
  identifier             = "second-terra-db"
  allocated_storage      = 10
  db_name                = var.db_name
  engine                 = "mysql"
  engine_version         = "8.0"
  instance_class         = "db.t2.micro"
  username               = var.db_username
  password               = var.db_password
  parameter_group_name   = "default.mysql8.0"
  db_subnet_group_name   = aws_db_subnet_group.second-subnet.name
  vpc_security_group_ids = [aws_security_group.second-sg.id]
  publicly_accessible    = true
  skip_final_snapshot    = true
}

The value, publicly_accessible is set to true only for the sake of this tutorial. You would not want set this configuration as 'true' for a database in a production environment.

Set skip_final_snapshot as 'true' if you do not want a snapshot of the instance to be taken upon deletion.

Managing Sensitive Variables

Sensitive values like the database password, username and db_name should not be written in plain text. These variables should first be declared as input variables in the variables.tf file:

variable "db_name" {
  description = "Database name"
  type        = string
  sensitive   = true
}

variable "db_username" {
  description = "Master Username"
  type        = string
  sensitive   = true
}

variable "db_password" {
  description = "Master password"
  type        = string
  sensitive   = true
}

Variables declared as sensitive are redacted from Terraform's output when commands like apply, plan or destroy are executed. However, note that these values will appear as plain text in the terraform state files, so ensure that the state file is kept safely.

With this, each time you run terraform apply, you will be prompted to enter the value of each variable, but this can be quite time consuming and error prone. To solve this, Terraform supports setting values within a variable definition(.tfvars) file.

Create a new file called secrets.tfvars, and assign values for the variables which were created earlier.

db_name     = "databaseName"
db_username = "username"
db_password = "insecurepassword1"

Now, the variables with values can easily be used with terraform apply:

terraform apply -var-file=secrets.tfvars

Since these values are sensitive, make sure to maintain and share the tfvars file with only the appropriate people and also ensure you do not check these files into version control.

Configure the ElastiCache Redis Cluster

First create the elasticache subnet group. Here, we would use the subnets that belong to the vpc module:

resource "aws_elasticache_subnet_group" "second-cluster-subnet" {
  name       = "second-cluster-subnet"
  subnet_ids = module.vpc.public_subnets
}

The redis instance is then created as shown:

resource "aws_elasticache_cluster" "second-cluster" {
  cluster_id           = "second-cluster-id"
  engine               = "redis"
  node_type            = "cache.t4g.micro"
  num_cache_nodes      = 1
  parameter_group_name = "default.redis5.0"
  engine_version       = "5.0.6"
  port                 = 6379
  security_group_ids   = [aws_security_group.second-sg.id]
  subnet_group_name    = aws_elasticache_subnet_group.second-cluster-subnet.name
}

The security group that was created earlier is used here.

Configure the Lambda Function

This is done last so that some output from the above configurations can be used as input to the Lambda function.

Firstly, create an IAM role for that will be used to manage the Lambda function. This role should have the permission to create a VPC. This would enable the function connect to the VPC that was created earlier.

data "aws_iam_policy_document" "assume_role" {
  statement {
    effect = "Allow"

    principals {
      type        = "Service"
      identifiers = ["lambda.amazonaws.com"]
    }

    actions = ["sts:AssumeRole"]
  }
}

resource "aws_iam_role" "iam_for_lambda" {
  name               = "iam_for_lambda"
  assume_role_policy = data.aws_iam_policy_document.assume_role.json
}

resource "aws_iam_role_policy_attachment" "AWSLambdaVPCAccessExecutionRole" {
  role       = aws_iam_role.iam_for_lambda.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole"
}

Since Lambda does not install any python packages, a lambda layer is created where all the modules used in our Lambda function are installed:

resource "aws_lambda_layer_version" "function_packages" {
  filename            = "./code/packages.zip"
  layer_name          = "function_packages"
  compatible_runtimes = ["python3.9"]
}

The filename should be the relative path to this package folder and compatible_runtimes is a list of runtime environments where the layer can work. Using Lambda layers is good because they enhance reusability.

Next, create and archive for the Lambda function itself:

data "archive_file" "lambda_function" {
  type        = "zip"
  source_file = "./code/lambda_function.py"
  output_path = "deployment_payload.zip"
}

type can be a zip file or an s3 bucket. For larger file sizes, it is advisable to use s3 buckets.
source_file: path to the source code file
output_path: the file name were you want the zip of the function to be stored in. It does not have to be an existing file as it is created by terraform.

Finally, the configuration for the Lambda function is as follows:

resource "aws_lambda_function" "first_lambda" {
  filename      = "deployment_payload.zip"
  function_name = "first_function"
  role          = aws_iam_role.iam_for_lambda.arn
  handler       = "lambda_function.lambda_handler"
  layers        = [aws_lambda_layer_version.function_packages.arn]
  timeout       = 150

  source_code_hash = data.archive_file.lambda_function.output_base64sha256

  runtime = "python3.9"

  vpc_config {
    subnet_ids         = module.vpc.public_subnets
    security_group_ids = [aws_security_group.second-sg.id]
  }

  environment {
    variables = {
      MYSQL_HOST     = aws_db_instance.firsTerraDB.address
      MYSQL_PORT     = aws_db_instance.firsTerraDB.port
      MYSQL_USER     = aws_db_instance.firsTerraDB.username
      MYSQL_PASSWORD = aws_db_instance.firsTerraDB.password
      MYSQL_DB       = aws_db_instance.firsTerraDB.db_name

      REDIS_URL  = "${aws_elasticache_cluster.second-cluster.cache_nodes.0.address}"
      REDIS_PORT = "${aws_elasticache_cluster.second-cluster.cache_nodes.0.port}"
    }
  }
}

In case your Lambda function uses some environment variables, they can be passed directly to the resource upon creation within the environment block.

Deploying the Resources

To provision the RDS instance, Redis Cluster, Lambda function and additional resource, first initialize the Terraform configuration:

terraform init

Next, apply the configuration.

terraform apply -var-file=secrets.tfvars

Terraform will now provision your resource. It may take some time for this to complete then you will see a message like:

You can visit your AWS management consoles to view the various resources and test your Lambda function to ensure the connections to the Redis Cluster and the MySQL instance were established.

Output Variables

Another way to view if our configuration details is to work with output variables.

In an outputs.tf file, define the values of the resources you want Terraform to show you after the configuration is applied:

output "redis_host" {
  description = "Redis Host"
  value       = aws_elasticache_cluster.second-cluster.cache_nodes.0.address
  sensitive   = false
}

output "redis_port" {
  description = "Redis port"
  value       = aws_elasticache_cluster.second-cluster.cache_nodes.0.port
  sensitive   = false
}

output "mysql_host" {
  description = "mysql host"
  value       = aws_db_instance.firsTerraDB.address
  sensitive   = false
}

output "mysql_port" {
  description = "mysql port"
  value       = aws_db_instance.firsTerraDB.port
  sensitive   = false
}

output "elasticache-sg" {
  description = "Elasticache security group name"
  value       = aws_elasticache_cluster.second-cluster.security_group_ids
}

output "database-sg" {
  description = "database sg"
  value       = aws_db_instance.firsTerraDB.vpc_security_group_ids
}

When terraform apply is executed, all this values would be displayed in displayed in the terminal.

Clean Up Infrastructure

In this tutorial, you have provisioned an RDS instance, a Redis cluster and a Lambda function using Terraform.
Clean up the infrastructure you created with:

terraform destroy -var-file=secrets.tfvars

How to Connect AWS Lambda to an Amazon ElastiCache Redis Cluster

Tambe Salome — Tue, 12 Sep 2023 10:26:57 +0000

Introduction

Amazon's ElastiCache is a service that enables you to launch, manage, and scale a distributed in-memory cache. It has multiple use cases caching, real-time analysis, machine learning, and session storage.

The focus of this tutorial would be on the caching use case with Redis. Applications that already use Redis can use ElastiCache with very little modifications.

Note: Make sure to delete your cluster when you are done using it in order not to incur additional cost. Visit this site to see more about ElastiCache pricing

Creating an ElastiCache Redis Cluster

From your AWS Management Console, click on Services and navigate to Database where you would find ElastiCache. Click on it to open your ElastiCache console.

In the side bar, under Resources, click on Redis Cluster. The window show you all Redis clusters you have. To create a new cluster, click the Create Redis Cluster at the top.

Select Easy Create for the cluster creation method, and choose Demo for the configuration type.

Give your cluster a name and a brief description.

Under Connectivity, set the network type to IPv4, select Choose an existing subnet group and select the subnet group we used for the Lambda function.
Click on Create to create your resource.

Connecting the Redis Cluster to a Lambda Function.

Learn how to setup an AWS Lambda function from from this article

In the Lambda function, navigate to the Configuration tab and on the side panel select VPC.

In order to connect the Redis instance to the Lambda function, add the security group that the Redis instance belongs to the Lambda function.

Click on Edit and under Security groups, select the Redis instance's security group and then save to update your configuration.

Import Redis in your function and include the redis connection string in your code. For python:



from redis.cluster import RedisCluster

cache = RedisCluster(host="mycache.xxxx.xxx.xxx.cache.amazonaws.com", port="6379")

The host can be the the Configuration endpoint if you have only one node, or the Primary endpoint or the endpoint of the node you need to assess. In this tutorial, the configuration endpoint is used which can be found under Cluster details in your redis cluster's dashboard.

You can test your configuration with this piece of code:



if (cache.exists('names')) :
        return {
            'statusCode': 200,
            'body': cache.get('names')
       }
else :
        cache.set('names', "hello world")
        return "Done!"

How to Setup an AWS Lambda Function with Python and Connect with an Amazon RDS Database.

Tambe Salome — Mon, 11 Sep 2023 11:56:25 +0000

Introduction

AWS Lambda introduces a concept known as serverless infrastructure. It is serverless in the sense that you don't have to worry about managing or provisioning of servers. They can automate operational processes, as well as complex application processes.

AWS Lambda's main resource are Lambda functions which are used to perform specific tasks.

Deploying a Lambda Function with Python

Prerequisites

To follow this tutorial, you will need an AWS account. If you do not have one yet, you can follow this guide on how to set-up your environment.
The steps described here are under the Free Tier, so feel free to play around.

Create a Lambda Function

Visit the AWS Management Console and under Services select the Compute tab and you'll find the Lambda service. Select it to open the Lambda Console.

In the Lambda console, navigate to Functions on the left pane and select it. This window shows you all the Lambda functions you have previously create and if there are none yet, no data would be displayed in the table.
At the top of this table, click the Create Function button to start creating your Lambda function.

There are 3 options you could choose from to create a Lambda function; author from scratch, use a blueprint to build from sample code with configuration presets, and deploying the function from a container image.
For this tutorial, we will use the Author from scratch option
In the Basic Information section, set the Function Name, choose the language version to use for your function for Runtime, select Architecture making sure it's compatible with the environment where you will build your deployment package(if applicable), and you can change the permissions for the execution role.
We will use Python 3.9 as our runtime environment and x86_64 architecture.

In Advanced Settings, you could enable Code signing to ensure the integrity your code, enable function URL to make your function accessible over http(s), enable tags or VPCs. For this tutorial, we will leave all this options unchecked and click the Create Function button to create the lambda function.

Lambda creates your function. You can use the console to modify your function's code or you could also upload from an S3 location or zip.
The function was created with some basic code that returns a status code of 200 and "Hello from Lambda" text.

The lambda function handler [in our case lambda_handler()] is the method that processes events. The lambda runtime passes two arguments to the function handler;
- Event Object: json formatted and contains data for the lambda function to process
- Context Object: provide methods and properties that provide information about the invocation, function and runtime environment and it is passed to the function by Lambda at runtime.

To test this, choose the Test tab. To invoke your function without saving the test event, click on Invoke, lambda preserves the event only for as long as the session.
Create a saved test by filling in the event details and choosing Save then on Test to invoke the function.
If you have a saved test even, you can also edit it.

View the results of the test in the Execution results tab. We can see that our function executed successfully and returned the desired result.

Include Python Dependencies to Lambda function: Deployment Packages

import json
import mysql.connector;

def lambda_handler(event, context):
    # TODO implement
    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }

If we include the above code in our console, and test it, an error is returned stating the mysql module can't be found. This is because lambda is not prepackaged with all libraries and does not install any.

Hence, if your code contains dependencies, you have to include them by using a deployment package or a lambda layer. We will be looking at including these dependencies using a .zip deployment package.

Creating the Deployment Package

Navigate to the the directory containing your lambda function on your computer, lambda_function.py, in this case firstFunction.

cd firstFunction

Create a directory where you would install your dependencies

mkdir packages

Install your dependencies in this directory. In this instance, we will install mysql-connector-python using pip, which enables connection to a mysql database. If you created your packages, simply save them to the packages folder.

pip install --target ./packages mysql-connector-python

Create a zip file with the packages folder at the root

cd packages
zip -r ../deployment_package.zip .

Add your lambda function to the root of the deployment package. The deployment package has to have a flat directory structure with everything at the root, if not, Lambda won't be able to run the code.

cd ..
zip deployment_package.zip lambda_function.py

Under the Code tab, select Upload and click on .zip file and select the deployment_package.zip file you created earlier.
For packages bigger than 50MB, it is advised to upload it to an S3 bucket then connect to the S3 location.

This now works seamlessly.

Note: You could still do changes to your function directly on the console. Always click on Deploy to save your changes before executing.

Connecting an RDS database to the Lambda Function

To get started with Amazon RDS for MySQL, visit this article.

After you have created your MySQL instance, include the Lambda function in the same VPC as the MySQL RDS instance in order for them to communicate.

In order to add the VPC to the Lambda function, you first need to modify the permissions attached to the role managing the function. To do this, open the IAM service in a new tab, click on Dashboard then on Roles.

Select the role that manages your lambda function, the name would have your function name and some random characters. Create a policy that enables it to create and delete network interfaces. We will AWSLambdaVPCAccessExecutionRole policy for that, but you also have the ability to write your own policies.

Edit the Lambda function's VPC by navigating to the Configuration Tab, then select VPC on the side menu and click Edit to add or edit a VPC.

Return to your RDS instance's dashboard. Click on the Actions drop down and select Set up Lambda connection.

In the Select Lambda function section, select your lambda function from the dropdown.

In the RDS Proxy section, leave the Connect using RDS Proxy unchecked to stay within Free Tier.

You can use an RDS proxy to simplify your database connection and minimize your application from disruptions caused by database unavailability.

Click on Set up to create the connection to the lambda function.

Add the mysql connection string to your python handler function.

mydb = mysql.connector.connect (
           host = "<rds_instance_endpoint>",
           port = <rds_instance_port>,
           user = "<master_username>",
           password = "<master_password>",
           database = "<database_name>"
          )

If you used an RDS proxy, host url should be the endpoint of the proxy instead.

The database_name is the name of any database running on the RDS instance in use. You can create one by connecting to this instance from the mysql CLI or an editor and running the query to create a database.

With all this in place, you will be able to query your database from the lambda function.

Troubleshooting

Runtime Error: Handler Not Found

"errorMessage": "Handler 'lambda_handler' missing on module 'lambda_function'",
  "errorType": "Runtime.HandlerNotFound"

This error occurs when Lambda can't resolve the Handler. Navigate to Runtime Settings in your function's dashboard and click Edit to modify the Handler. The Handler should have the format: fileName.functionName

How to Deploy a Managed MySQL Instance in an Amazon RDS Database.

Tambe Salome — Sun, 03 Sep 2023 10:14:22 +0000

Introduction

Amazon Relational Database Service (RDS) is a web-service that makes it easier to set-up, operate, and scale-up relational databases in the cloud and manages common administration tasks. Amazon RDS currently supports the MariaDB, MySQL, Oracle, PostgreSQL, and Microsoft SQL engines.

AWS currently offers more than 15 purpose-built database options to support various database models. These models include: relational, key-value, in-memory, graph, time-series, wide-column and ledger databases.
To choose what model to use, you should consider; The business objective, migration strategy from on-premise database to the cloud, purpose-built optimized for what you need, data considerations, security considerations and much more. To fully understand how to choose the best database service for your business, you can visit AWS Decision Guide

In this tutorial, we will be discussing how to deploy a managed MySQL instance using an Amazon RDS database. A managed service is preferred to setting it up manually on an EC2 instance because it fully provides continuous monitoring, self-healing storage, and auto-scaling to help you focus on the application development and your users.

Amazon RDS for MySQL

Prerequisites

Create a MySQL DB Instance

To get started, open the AWS Management Console, then select Services on the left of the top pane. This would display a list of services offered by AWS from Databases, to Containers and much more. Since we are interested in the Database service, we click on it, then choose RDS to open the Amazon RDS console

In the Amazon RDS Console, the first thing to do is choose the region in which we want to create the database. Note: Some regions are inaccessible depending on your account type.

Regions are isolated form other regions as a fault tolerance and stability mechanism and also, data is not automatically transferred from one region to another. So, if you switch regions, you won't find the same data in the new region.

To create the database, scroll to the Create database section and choose Create database

If you would like to set your own configuration options including those for availability and security upon creation, the Standard Create option should be used, otherwise, you can go with Easy Create which uses the recommended best practices to configure your database some of which can be changed after creation.

Select the engine you would want to run from the list of Engine options supported by RDS. For the purpose of this tutorial, the MySQL engine would be used and the default version and edition should be maintained. Select the Free Tier template

A Region has multiple isolated locations known as Availability Zones. Enabling Multi-AZ deployments would automatically provision and maintain a synchronous standby in other Availability Zones to ensure fault tolerance in case of failure of one zone. However, this is a paid feature, so it'll not be discussed in this tutorial.

The next thing to do is define some key settings for the DB instance. These include;

DB Instance Identifier : unique name across all DB instances owned by your AWS account in the current region.

Master Username: the username that will be used to login to the mysql instance.

Master password: A password that contains at least 8 ASCII characters (excluding ', ", @, and /)

Confirm master password: Retype the password you had above

For the instance specification, select the db.t2.micro — 1vCPU, 1 GiB RAM for the Instance Type, General Purpose (SSD) for Storage Type and 20 GB for Allocated Storage. This specifications ensure we stay in the Free Tier range. For more about RDS pricing, see Amazon RDS pricing

Autoscaling should be enabled for unpredictable workloads but that is beyond the free tier usage capacity.

Under Connectivity, one key thing to take note of is the VPC. Amazon virtual private cloud (VPC) makes it possible to launch AWS resources into a virtual private cloud such that you can create your own subnets, access control lists, choose your own IP address and configure routing. There is no additional cost in running the DB instance in a VPC and all new DB instances are created in the default VPC except explicitly changed. For this tutorial, we'll use the default VPC.

Under VPC security groups, choose Create new. This creates an inbound rule that allows connection from the IP address of the device you are currently using to the database created.

Also, make sure your DB instance is Publicly Accessible by setting this field to 'Yes' to make it possible to directly connect to the database from your device.

The RDS Proxy allows your applications to pool and share database connections, hence improving their ability to scale. We will leave this option unchecked. To see more on the pricing for RDS proxy, visit Amazon RDS Proxy pricing

The other settings are left as default for this configuration.

Database Authentication defines how you would want users to be authenticated before they can view the database. The options are:

Password Authentication; uses the database password only.

Password and IAM database authentication; uses the database password and the user's credentials through IAM users and roles. This option is available only on MySQL and PostgreSQL engines.

Password and Kerberos authentication; uses the database password and kerberos authentication through AWS Managed Microsoft AD created with AWS Directory Service.

For simplicity, choose the Password Authentication method from the list of options.

To stay within the free tier, leave the Enable Enhanced Monitoring unchecked. Monitoring gives you metrics in real time for the OS that the DB instance is running on.

In the Additional Configuration section, under Database options, the Initial Database Name is the name of your database on you DB instance. If a name is not provided, RDS does not create a database while creating (except for Oracle or PostgreSQL). We would use the default Option Group and DB parameter group. Sometimes, you might have the ability to create your own DB parameter group or Option Group.

RDS creates a storage volume snapshot of the entire database instance, backing up the entire database instance and not just particular databases.
Under Backup, check the option to Enable automated backups.

The Backup retention period determines the number of days for which the automatic backups are kept, for this tutorial, set it to 1 day.

If you would like to set a daily time range during which backups should occur, select Choose a window option and set the time for your preferred window. If not, you can just select No preference which is what we will do here.

Turn on Enable auto minor version update under Maintenance. This will allow us to receive automatic updates when they become available. Just like in Backup, we can set the set a particular maintenance window or select no preference.

The last thing we'll need to do is turn off Enable deletion protection for this tutorial. Enabling this option will prevent you from accidentally deleting your database.

Voila! Select Create Database to create the DB instance.

This might take a while depending on the instance class and storage allocated for the database. When the status changes to Available, then your instance has been completed.

While this is creating, you can move on to the next step of setting up your MySQL environment on your local computer.

Connect to the MySQL Database

In this step, we will connect to the MySQL database that was created using the MySQL CLI. Before moving on, make sure you have installed the MySQL CLI. The connection string is:

mysql -h  **_endpoint_**  -P  **_port_**  -u  **_user_**  -p

The endpoint and port for the database can be found under the Configuration and Security tab. The user is the Master Username that was set when creating the database which can be found under the Configuration tab.
When you click enter, you'll be prompted for a password, this would also be the Master password which was also set upon creation of the DB instance

And Voila, you're connected to your database. If we display the list of databases, we would see some default databases that come with MySQL and also the database we created when creating the instance.

And that's how we connect to the Amazon RDS MySQL Database instance.
Congratulations. Now you can insert data and run queries. You could also create new databases.

Delete the DB Instance

In order not to waste resources and incur cost over time, it is best we delete the DB instance if you are not using it.

To do so, return to the RDS console. Choose Databases, then select the instance you want to delete and under Actions dropdown, select Delete.

You would be asked if you want to create a final snapshot of your database. Select this option if you would like to restore the current state of your database with all its data in future. For this tutorial, we would leave that option unchecked.

Confirm that you want to delete the instance and then click Delete

Performing these actions would permanently delete the database instance.

Conclusion

In this tutorial, we have seen what an Amazon RDS database is and why it is preferred to manually setting up your own database. We also looked at the various engines that are supported by RDS and focused on using the MySQL engine to create a MySQL database instance on the RDS service. Then, we were able to connect this remote instance to our local computer and run basic queries. Finally, we saw how to permanently delete the database instance.

Troubleshooting

If you restart your network, the VPC security group that created the inbound function permitting you to connect to the instance from your computer might not work anymore because your computer's IP address might have changed.

To fix this, select your database and under Connectivity and Security select your VPC security group under VPC security groups.

This would take you to the Security Groups page where you can see your different security groups, the outbound and inbound rules and configure them. Inbound rules define what resources are permitted to connect to the instance and Outbound rules define what resources the instance is permitted to make a connection with.
From here, we can go ahead and edit our inbound rules in order to permit our device to connect with it.

The only thing you will need to edit here is, under Sources of the rule, select My IP to change the IP address the resource is allowed to connect to, to your device's IP address. Click on save rules, and now, you will be able to connect like before.