Forem: Ismail G.

Day 1 — Root Security & IAM Identity Center

Ismail G. — Sun, 19 Apr 2026 12:23:59 +0000

In my ongoing startup infrastructure series, I began by securing the most critical part of any AWS account: the root user and access management layer.

This first step is simple, but extremely important: lock down root access and establish a proper identity system.

A complete hands-on version of this setup is also available on GitHub repo:
https://github.com/skysea-devops/startup-aws-infra-setup-guide/tree/main

Why This Setup Is Important

This setup is aligned with AWS best practices, particularly the AWS Well-Architected Framework principles:
https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html

The root account in AWS has unlimited permissions. If compromised, everything is exposed: infrastructure, data, billing, and even account ownership.

At the same time, poorly managed access (shared credentials, no MFA, direct IAM users) becomes chaos very quickly in a growing startup.

So the goal of Day 1 is clear:

Secure root access
Eliminate risky login patterns
Establish scalable access control via IAM Identity Center (SSO)

Step 1 — Enable MFA on Root Account

The very first thing you should do after creating your AWS account is enabling Multi-Factor Authentication (MFA).

Avoid relying only on passwords. MFA ensures that even if your credentials leak, your account remains protected.

Setup Flow

Go to: Account → Security Credentials → MFA → Assign MFA
Choose Authenticator app
Scan QR code with your phone
Enter two consecutive codes

Once completed, AWS will confirm:

“You have successfully assigned this virtual MFA device.”

At this point, your root account is significantly more secure.

Important Rule

Never use the root account for daily operations.

Use it only for:

Billing
Account-level changes
Emergency recovery

Step 2 — Enable IAM Identity Center (SSO)

After securing root, the next step is eliminating direct access usage and moving to a centralized identity system.

AWS provides this via: IAM Identity Center (formerly AWS SSO)

Why IAM Identity Center?

Instead of creating IAM users, sharing credentials across team members, and manually managing passwords, you can adopt a much more structured and secure approach.

By using IAM Identity Center, you gain centralized access control, a seamless SSO login experience, built-in MFA enforcement, and a cleaner, more scalable DevOps workflow overall.

Search in AWS Console:

IAM Identity Center → Enable

At this stage, AWS gives you two options for enabling IAM Identity Center:

Account instance (single account) Organization instance (recommended)

Since I’m building this setup for a startup with scalability in mind, I chose:

Enable with AWS Organizations

You must choose a region.

Recommended:

eu-west-1 us-east-1

This choice is not easily changeable later, so pick carefully.

Encryption (KMS)

Under Advanced Configuration, AWS asks:

Key for encrypting IAM Identity Center data at rest

You have two options:

Use AWS owned key (recommended for most startups)
Use a custom KMS key (advanced)

For now, I selected:

Use AWS owned key

Reason:

Simpler setup
No key management overhead
Fully secure for standard use cases

You can always migrate to a custom KMS later if needed.

Step 2 — Create Permission Sets

At this stage, IAM Identity Center is enabled, but no one has access yet. Before creating users, you need to define what kind of access they will have.

This is done through Permission Sets. Think of these as role templates.
Navigate to:

IAM Identity Center → Permission sets → Create permission set

Name      | Policy               | Use Case
Admin     | AdministratorAccess  | Founders / Infra
PowerUser | PowerUserAccess      | DevOps / Engineers

Admin Permission Set

Full access to all AWS services
Should be limited to very few users
Used for infrastructure ownership

PowerUser Permission Set

Broad access to services
Cannot manage IAM
Ideal for developers and DevOps engineers

Step 3 — Create Your First User

IAM Identity Center → Users → Add user

Define:

Username
Email address
First & last name

AWS will send an invitation email for first-time login.

Step 4 — Assign Access

This is where everything connects. You now link:
User → AWS Account → Permission Set

Navigate:
IAM Identity Center → AWS Accounts → Assign users or groups

Assignment Flow
Select AWS Account

Select User (or Group)

Choose Permission Set

Confirm

Step 5 — Enforce MFA for All Users

Even though root MFA is enabled, you must enforce MFA for all SSO users. Because MFA:

Protects against credential leaks
Enforces security across the team
Standard best practice for any production setup

Navigate to:

IAM Identity Center → Settings → Authentication → Require MFA

Access Portal Login:

Users will log in through a centralized access portal provided by AWS, using a unique URL such as https://xxxx.awsapps.com/start. This portal acts as the single entry point for all users, where they authenticate with their credentials and complete MFA verification before accessing their assigned AWS accounts and roles.

After logging in through the Access Portal URL, users are presented with a centralized dashboard where they can see all AWS accounts and roles assigned to them.

At this point, the AWS account is no longer a single-user environment but a structured, secure, and scalable access system. This foundation is critical before provisioning any infrastructure.

Building Startup Infrastructure the Right Way

Ismail G. — Tue, 14 Apr 2026 17:16:02 +0000

I recently started working on a systematic "30-day startup infrastructure plan" and have been working on my GitHub repo step by step. The goal is simple: I want to construct a clean, production-ready infrastructure from the start. I also want the whole process to be open and easy to follow.

Most teams in the early stages don't really design their infrastructure. They put it together. You set up a server, add a database, and configure a deployment. Everything works well enough to carry on. This method makes sense, especially when time is of the essence. But it also hides risks that only show up when the system starts to grow.

Why Infrastructure Becomes a Problem Later

Startups generally don't think about infrastructure as a top priority. The main things to work on are product development, getting new customers, and how quickly you can make changes. But decisions about infrastructure discreetly affect how a product works when it's under stress. They decide how easily a team can make changes, how safely data is managed, and how reliably the system responds to more demand.

When the first setup is done without a plan, the difficulties usually show up later. It gets tougher to maintain systems, deployments become less stable, and debugging takes longer. Instead of giving you confidence, scaling makes things less certain. At that point, teams have to spend time correcting problems that shouldn't have happened instead of adding new features.

What It Means to Get It Right Early

This is why I think we should plan for infrastructure from the start. This doesn't mean making things too complicated or establishing systems that are too complicated too soon. It includes setting a clear baseline for things like safe access control, well-segmented environments, automated deployments, and being able to see how the system works. These things are not extras; they are the bare minimum for long-term progress.

In this case, cloud platforms like AWS provide a great base for new businesses. They let you start small and grow over time, and they still let you use best practices like managed services, identity management, and network isolation.

AWS provides scalable, secure, and cost-effective infrastructure tailored for startups, featuring over 200 fully featured services. Key offerings include compute (EC2), storage (S3), databases (RDS), and networking (VPC).

AWS lets teams construct systems that are ready for production and don't cost too much. More crucially, it allows an infrastructure-as-code approach, which makes it easier to keep environments the same and manage them over time.

Making This Work in Real Life

My current goal is to bring all these pieces together in a meaningful and easily understandable way. To build a real infrastructure step-by-step and document it. This covers everything from security setup for individual accounts to networking, computing, database architecture, CI/CD pipelines, and monitoring.

What's Next

This will be a series that shows how the setup really goes. The structure I'm constructing in my GitHub repository will match each stage, and each post will focus on a different layer of the infrastructure. The documentation will change as the system does.

You can follow both the my GitHub repository and the posts that will be coming out here if you want to learn how to construct startup infrastructure the proper way. As I go along, I'll share each step and explain not just what I'm doing but also why I'm doing it that way.

The next essay will be about the first step in the setup, which is building a secure and controlled base.

How I Became an AWS Community Builder (Data Track)

Ismail G. — Sat, 07 Mar 2026 07:17:26 +0000

I got an email a few days ago that made my day. I had been accepted into the Data track of the AWS Community Builders.

This initiative may just look like another badge for a lot of folks. But for me, it means a lot more: months of studying, trying new things, and sharing what I learn with other people.

After I told folks the news, a lot of them asked me the same thing: "What helped you get in?"

There is no one secret, to tell the truth. But one thing was really important: always sharing technical information. One of the best things I did on my trip was to write about my experiences with databases, cloud architectures, and AWS services on Dev.to.

In this article, I want to talk about what I accomplished, what made my application stand out, and what I would tell anyone who wishes to apply to the program in the future.

What is the AWS Community Builders Program?

Before diving into my journey, let's clarify what this program is. The AWS Community Builders program is designed to recognize and support technical community leaders who are passionate about sharing knowledge and connecting with others about AWS technologies.

It provides builders with technical resources, mentorship, $500 in AWS credits, exam vouchers, and a direct line to AWS product teams. It’s not just about what you know; it’s about how you help others learn.

Where I Started: My Background

At first, I focused mainly on getting AWS certifications. But after a while, I realized that passing an exam is really just the starting point. To truly understand the cloud, I needed hands-on experience—working through real database problems, experimenting, sometimes breaking things, and figuring out how they work.

Along the way, I also started documenting what I learned so others could benefit from the same experiences.

The Turning Point: Writing on Dev.to

At some point, I realized that simply learning new things wasn’t enough. I was spending hours troubleshooting systems, experimenting with databases, and figuring out how different AWS services worked together—but most of those lessons stayed in my own notes.

That’s when I started sharing what I learned on Dev.to.

Instead of writing simple notes for myself, I began turning real troubleshooting sessions into structured tutorials. Whenever I solved a problem, I tried to explain the process step by step—what went wrong, what I tried, and what finally worked.

Another place where I learned a lot was AWS re:Post. I started helping people who were facing real problems with AWS services. Sometimes the questions were about databases, sometimes about architecture or infrastructure.

When I encountered an interesting problem there, I didn’t just answer it and move on. I often recreated the scenario in AWS, tested different solutions, and then wrote a detailed article on Dev.to so that the solution could help more people facing the same issue.

Because I applied to the Data track of the AWS Community Builders, many of my articles naturally focused on data-related topics, such as:

AWS DocumentDB — exploring how managed NoSQL databases work in AWS
MongoDB migrations — the challenges of moving on-premise data to the cloud
Database architecture — designing systems for high availability and scalability
Cloud infrastructure — automating data workloads and deployments

Over time, something interesting happened. Writing about these topics didn’t just help others—it also helped me understand them much more deeply. Explaining a solution forces you to truly understand it.

One thing I learned along the way is this:

Don’t just write about what a service is. Write about the problem you solved with it.

That’s the kind of knowledge the cloud community values most.

Community Contribution & Engagement
A significant part of my journey consisted of writing articles; however, I quickly realized that being "constructive" wasn't just about producing content.

Being a member of a community is also an important element. Answering questions posted in online forums, participating in online discussions, and trying to help with challenging database configurations also gave me new experiences.

What Actually Matters When Applying?

If you are planning to apply for the next cohort, here are the four pillars that I believe made my application stand out:

I can't speak for the critics, but in my experience, four elements seem to be the most important:

Technical Information
High-quality blog posts, GitHub repositories, or films that indicate how deep your technical knowledge is and how much practical experience you have.

Consistency:
One article soon before the deadline won't do anything. If you post content regularly over a few months, it demonstrates you're actively participating.

Real-World Experience:
Your information is considerably more useful if you explain how you use AWS services to solve real problems, especially difficulties with infrastructure or data.

Community Impact:
Last but not least, your content should be useful to individuals. People talking about your ideas, leaving comments, and using them prove that your effort is helpful to the community.

My Advice for Aspiring Builders

If you’re thinking about applying to the AWS Community Builders, my biggest advice is simple: start sharing what you learn.

You don’t need to be an expert in everything. In fact, many of the articles I wrote started with something I had just learned while working on a real problem. Instead of keeping that knowledge to myself, I turned those experiences into tutorials and shared them with the community.

One thing that helped me a lot was writing about real challenges. Explaining how you solved a problem—whether it’s a database migration, an architecture decision, or a troubleshooting process—creates content that is actually useful for others.

Another important thing is consistency. You don’t need to publish something every week, but sharing your learning journey over time shows that you’re actively contributing to the ecosystem.

Finally, try to engage with the community whenever you can. Platforms like Dev.to or AWS re:Post are great places to both learn from others and help people solve real problems.

At the end of the day, the goal isn’t just to get accepted into the program. The real value comes from learning in public and helping others along the way.

A New Beginning

Becoming an AWS Community Builder is a milestone, but more importantly, it’s a beginning. It’s an invitation to learn more, share more, and connect with some of the brightest minds in the industry.

Are you planning to apply for the next round? Let me know in the comments if you have any questions about the process!

Secure Terraform CI/CD on AWS with GitHub Actions (OIDC + Remote State)

Ismail G. — Sun, 08 Feb 2026 21:40:52 +0000

For CI/CD processes to work well, they need to be secure and repeatable. Without a strong authentication system and a consistent state management strategy, infrastructure automation quickly becomes vulnerable to security threats.
This blog post explains how to set up a remote Terraform backend with state locking using Amazon S3 and DynamoDB. We will also use OIDC to set up keyless authentication from GitHub Actions to Amazon Web Services (AWS).

Amazon S3 – remote state storage (versioned & encrypted)
DynamoDB – state locking
AWS KMS – encryption
GitHub Actions – CI/CD automation

Why This Setup Matters

AWS access keys are saved as secrets in traditional continuous integration pipelines. This plan is very risky because long-lived credentials could be stolen.

Key rotation is hard, but it's necessary. When CI is compromised, AWS is also compromised.

OpenID Connect (OIDC) solves this problem by letting GitHub Actions get an IAM role dynamically using short-lived credentials from AWS STS.

Terraform also needs to use a remote backend to:

Stop the state from getting corrupted at the same time.
Take care of values that are weak.
Make sure that people can work together.

This architecture solves both of these problems in a way that is easy to use and can grow with your needs.

High-Level Architecture:

GitHub Actions requests an OIDC identity token
AWS validates the token using IAM OIDC Provider
An IAM Role is assumed via sts:AssumeRoleWithWebIdentity
Terraform runs with temporary credentials
State is stored in encrypted S3, locked via DynamoDB

Step 1️: Create AWS OIDC Provider

To allow GitHub Actions to authenticate with AWS, an OIDC provider must be configured in AWS IAM. Before this, if you do not have AWS CLI configured in your local computer, you must setup it.

AWS CLI Setup (macOS)

# Homebrew
brew install awscli

aws --version

aws configure

write those when asked:
AWS Access Key ID [None]: <your-accesskey>
AWS Secret Access Key [None]: <your-secret-accesskey>
Default region name [None]: <region-name>
Default output format [None]: json

# Account test
aws sts get-caller-identity

Create the OIDC Provider

Run the following command using AWS CLI or create the provider via the AWS Console.

aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1

This enables AWS to validate GitHub-issued identity tokens.

Step 2️: Create IAM Role for GitHub Actions

Next, an IAM role must be created so that GitHub Actions workflows can assume it using sts:AssumeRoleWithWebIdentity.

This role explicitly defines:

Who can assume it (GitHub Actions)
From which repository it can be assumed

Create GitHubActionsRole with trust policy sts:AssumeRoleWithWebIdentity

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::YOUR_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:YOUR_GITHUB_USERNAME/YOUR_REPO_NAME:*"
        }
      }
    }
  ]
}

Attach IAM Policy

For bootstrap simplicity, we attach AdministratorAccess.
Important:
In real production environments, replace this with least-privilege policies.

Step 4️: Configure GitHub Repository Secret

GitHub Actions must now be informed which IAM role to assume.

In the GitHub repository: Settings → Secrets and variables → Actions → New repository secret

Create the following secret:

AWS_ROLE_ARN = arn:aws:iam::YOUR_ACCOUNT_ID:role/GitHubActionsRole

Step 5️: Terraform Remote State

We use a one-time bootstrap workflow to provision:

S3 bucket (versioning + encryption)
DynamoDB table (state locking)
KMS key (state encryption)

Repository Structure

terraform-remote-state/
├── main.tf
├── providers.tf
├── variables.tf
├── terraform.tfvars

From my GitHub repository you can check the terraform files:

GitHub Repo

Step 6️: Bootstrap GitHub Actions Workflow

Below is the final bootstrap workflow.

Uses OIDC for AWS auth

Accepts the S3 bucket name as an input

Pins Terraform version

Verifies AWS identity before provisioning

bootstrap.yml

# This workflow creates the foundational infrastructure for Terraform:
# - S3 bucket for state storage with encryption and versioning
# - DynamoDB table for state locking (prevents concurrent modifications)
# - KMS key for encrypting state files and secrets
#
# Run this ONCE before deploying main infrastructure

name: Bootstrap 

on:  
  workflow_dispatch:

permissions:
  contents: read
  id-token: write

env:
  AWS_REGION: us-east-1
  TF_VERSION: 1.5.0  

jobs: 
  bootstrap:  
    runs-on: ubuntu-latest 

    defaults:
      run:
        working-directory: terraform-remote-state

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}
          role-session-name: GitHubActions-Bootstrap

      - name: Verify AWS identity
        run: |
          echo "Authenticated as:"
          aws sts get-caller-identity

          ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
          echo "AWS Account ID: $ACCOUNT_ID"
          echo "AWS Region: ${{ env.AWS_REGION }}"

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: ${{ env.TF_VERSION }}

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: |
          terraform plan -out=plan.tfplan

      - name: Terraform Apply
        run: terraform apply -auto-approve plan.tfplan

      - name: Terraform Output
        run: terraform output

Step 7️: Run the Bootstrap Workflow

Go to GitHub Actions

Select Bootstrap

Click Run workflow

Step 8️: Store Terraform Outputs as GitHub Secrets

After completion, Terraform outputs values required by all future environments.
Store these as GitHub Secrets:
TF_STATE_BUCKET # S3 bucket name
TF_LOCK_TABLE # DynamoDB table name
KMS_KEY_ARN # KMS key ARN

Solving Frontend-Lambda Timeout Issues with AppSync Asynchronous Execution

Ismail G. — Sat, 29 Nov 2025 16:33:36 +0000

A common issue in serverless applications: the frontend receives a timeout error while CloudWatch logs show the Lambda function completed successfully. Users see failed requests, but backend operations succeed.

When a Lambda function is called synchronously, the API waits for it to complete and return a response. For long-running tasks, this might cause considerable delays.

Critical timeout constraints:

Layer	Maximum Timeout	Configurable
Lambda Function	15 minutes	Yes
API Gateway (REST)	29 seconds	No
AppSync (GraphQL)	30 seconds	No

The Solution: AppSync Asynchronous Lambda Execution

AWS AppSync provides asynchronous Lambda resolver support. Asynchronous execution lets a GraphQL mutation trigger a Lambda function without waiting for it to finish. The resolver returns immediately, bypassing the 30-second timeout limit.

With this pattern, the frontend is no longer tied to the duration of the Lambda execution. This enables long-running workflows to complete in the background.

```Before (Synchronous):
Frontend → "Start job" → Wait 30s → Timeout ❌
Lambda still running...

After (Asynchronous):
Frontend → "Start job" → Get job ID immediately ✅
Lambda runs independently → Updates result → Frontend gets notified ✅```

How It Works

When a GraphQL mutation is invoked with an async handler, AppSync invokes the Lambda function using Event invocation type (asynchronous mode). It returns a response—typically containing a job identifier—without waiting for Lambda completion.

The Lambda function then executes independently in the background. The frontend retrieves results through two methods:

Real-time updates: GraphQL subscriptions notify the client when data changes
Polling: Periodic GraphQL queries check job status at defined intervals

This architecture eliminates the 30-second AppSync resolver timeout limitation while maintaining a responsive user experience.

Implementation with AWS Amplify Gen 2

For Amplify applications using AppSync, AWS provides native support for asynchronous Lambda resolvers:

The frontend triggers a GraphQL mutation.
AppSync invokes the Lambda function in asynchronous mode and immediately returns a task reference.
The Lambda executes independently.
Results are written to a datastore.
The frontend retrieves results via follow-up GraphQL queries, or AppSync subscriptions (real-time updates).

AWS Documentation:

https://docs.amplify.aws/react/build-a-backend/data/custom-business-logic/#async-function-handlers

Get Hands-On with Amazon RDS Using AWS’s Getting Started Resource Center

Ismail G. — Sat, 02 Aug 2025 10:15:35 +0000

Understanding Amazon RDS (Relational Database Service) is essential for anyone seeking to gain expertise in cloud technology. You can't beat getting your hands on some real-world experience with managed databases, cloud-native application deployment, or even just learning the ropes of Amazon Web Services (AWS) certification.

Fortunately, the 'Getting Started Resource Center' on AWS provides a curated set of practical lessons tailored to RDS.

What is AWS RDS (Relational Database Service)

Amazon RDS is a managed relational database service provided by AWS (Amazon Web Services). Without worrying about the underlying infrastructure, users may quickly establish, operate, and scale databases in the cloud.

Launching and managing cloud-based relational databases is easy with Amazon RDS. It facilitates numerous engines, including MariaDB, SQL Server, PostgreSQL, and MySQL, and it hides numerous tedious processes, such as backups, scalability, replication, and patching.

Getting RDS knowledge empowers you with the ability to:

Database provisioning that is both secure and scalable

Redundancy and high availability

Tracking and automating performance

Managing a database instance and integrating third-party applications

Unless you have hands-on experience with database launch, connection, and management, these concepts may appear abstract. The value of AWS's practical guides becomes apparent in this context.

Hands-On RDS Tutorials Currently Available

As of now, AWS offers three dedicated hands-on labs for Amazon RDS, each addressing a key learning scenario:

Create and Connect to a MySQL Database

Ideal for beginners
Learn how to launch a MySQL RDS instance, configure access, and connect with a client
Free Tier–eligible

Create and Connect to a Microsoft SQL Server Database

Similar structure, but uses SQL Server as the database engine
Great for Windows-centric or enterprise developers
Learn connectivity, security, and basic DB management

Amazon RDS Backup & Restore Using AWS Backup

Learn how to create an on-demand backup job for an Amazon RDS database
Practice backup planning and restore workflows
Valuable for DevOps and system reliability engineers

Why AWS Hands-on Tutorials Are Valuable

While the number of RDS-related hands-on tutorials is currently limited, they cover core operational skills that are widely applicable:

Almost every cloud project requires database creation and connection. The availability of data in production settings depends on the backup and restore processes.

The ability to use Microsoft SQL Server configurations will give you basic information about managing other databases.

Don’t just read about RDS—build with it. Let's start with this:
https://aws.amazon.com/getting-started/hands-on/amazon-rds-backup-restore-using-aws-backup/?ref=gsrchandson&id=itprohandson

Using SSL with a PostgreSQL DB Instance

Ismail G. — Sun, 15 Jun 2025 13:22:17 +0000

Protecting any app that deals with sensitive information means making sure that it is safe while it is being sent. When you host PostgreSQL on Amazon RDS, it enables Secure Sockets Layer (SSL) connections.

This means that data transfers between your app and the database can be protected. This makes sure that private information is safe from being intercepted or changed while it is being sent.

This post will show you how to use SSL with a PostgreSQL DB instance on Amazon RDS, including what you need to do first, how to set it up, and the best ways to do so.

Enabling SSL on Your RDS PostgreSQL Instance

By default, Amazon RDS for PostgreSQL supports SSL. But to make SSL work and set up your client correctly, you need to do a few more things.

1. Check the SSL Configuration

Go to your RDS instance in the AWS Console and review the associated parameter group. If you are using PostgreSQL version 15 or newer, rds.force_ssl may be enforced by default.

Navigate to RDS > Databases > [your database] > Configuration

Open the linked Parameter group

Find the rds.force_ssl parameter:

If set to 1, SSL is required.
If set to 0, SSL is optional.

2. How to Enforce SSL in RDS (If SSL is not Enforced in RDS)

If rds.force_ssl parameter is 0 you must set it to 1. By default, parameter groups in AWS RDS are read-only and cannot be modified. Therefore, to enable rds.force_ssl = 1, you must create a custom parameter group.

Create a Custom Parameter Group:

By default, parameter groups in AWS RDS are read-only and cannot be modified. Therefore, to enable rds.force_ssl = 1, you must create a custom parameter group.

Go to RDS → Parameter groups → Click “Create parameter group”

Fill in the fields as follows:
- Parameter group family: postgres14
- Group name: custom-postgres14-ssl
- Description: Enable SSL for PostgreSQL 14
Click Create

Set rds.force_ssl = 1 in your new parameter group:

Select your newly created parameter group
Click “Edit parameters”

Search for rds.force_ssl and change its value from 0 ➝ 1
Click Save

Attach the custom parameter group to your RDS instance:

Go to RDS → Databases → Click your instance (database-1)
Click “Modify”

In the DB parameter group dropdown, select the custom group:
custom-postgres14-ssl

Scroll to the bottom and choose 'Apply immediately'.

Click “Continue” and then “Apply changes”

3. Download the AWS RDS Root Certificate

To establish a secure SSL connection, you must download the root certificate authority (CA) file from AWS.

You can find the latest region-specific certificates here:
Using SSL with Amazon RDS PostgreSQL

Connecting with SSL

Once you’ve downloaded the certificate, you can connect to your RDS PostgreSQL instance using several methods.

Using a GUI Tool (e.g., DBeaver)

In your tool of choice, create a new PostgreSQL connection:

Enter the RDS endpoint, port (5432), database name, and credentials.
Under SSL settings:
- Enable SSL (usually a checkbox).
- Set SSL Mode to require or verify-ca.
- Upload the RDS Root CA certificate you previously downloaded.

Using Terminal (psql CLI)

You can also connect securely via the terminal:

psql "host=mydb.xxxxxx.rds.amazonaws.com port=5432 dbname=mydb user=myuser password=mypass sslmode=verify-full sslrootcert=rds-ca-2019-root.pem"

sslmode=verify-full: Ensures both certificate and hostname validation.

sslrootcert: Path to the downloaded certificate file.

This configuration helps ensure both confidentiality and integrity of the data transmitted.

For more information and certificate downloads, refer to the official documentation:
Using SSL with Amazon RDS PostgreSQL

Migrating from MongoDB to Amazon DocumentDB

Ismail G. — Sat, 17 May 2025 12:22:46 +0000

Modern applications today often use document databases. For years, MongoDB has been the preferred choice for developers to build applications using JSON-like document data structures. However, a move to a fully managed service like Amazon DocumentDB is attractive when workloads increase.

Built from the ground up, Amazon DocumentDB (with MongoDB compatibility) is highly available, robust, and scalable. It supports common MongoDB drivers and tools, making it easy to move teams without changing application code. This article will guide you step-by-step through migrating data from MongoDB to Amazon DocumentDB using the AWS Database Migration Service (DMS).

Prerequisites

Before you begin the migration, make sure you have the following:

An Amazon DocumentDB cluster already created and available in your AWS account.

We will use AWS Database Migration Service (DMS) to migrate data from a MongoDB database to Amazon DocumentDB. This will work with minimal downtime and will not require the export and import of collections manually.

Create an AWS DMS Replication Instance for MongoDB Migration

The replication instance is responsible for the actual migration process. It establishes a connection to the source and target endpoints, extracts the data, transforms it (if necessary), and then inserts it into the destination.

Access the AWS DMS Console and navigate to the Replication instances section.

Select "Create replication instance."

Pick an instance identifier and select an instance class, such as dms.t3.medium.
Select the appropriate virtual private cloud (VPC). This must be the same VPC that your DocumentDB cluster refers to as its home.
Multi-AZ should be activated when exceptional availability is required.
Select the "Create" button and await the "Available" status of the instance.

Create Source and Target Endpoints for MongoDB Migration

Once the replication instance is ready, create source and target endpoints to define where the data will be moved from and to.

Source Endpoint (MongoDB):

Endpoint type: Source
Engine: MongoDB
Server name: MongoDB hostname or IP address
Port: 27017
Database name: your MongoDB database (e.g., zips-db)
Authentication mode: default
Username and password: credentials for your MongoDB instance

Target Endpoint (Amazon DocumentDB):

Endpoint type: Target
Engine: MongoDB
Server name: your DocumentDB cluster endpoint (e.g., mydocdbcluster.cluster-xxxxxx.docdb.amazonaws.com)
Port: 27017
Database name: target database name
Authentication: enter your DocumentDB admin username and password
TLS mode: verify-full
TLS CA file: upload global-bundle.pem

To add TLS CA file,first download the global CA certificate. You can find the TLS certificate download command directly in the Amazon DocumentDB console under your cluster's Connectivity & security tab.

After both endpoints are created, test the connections to verify that DMS can reach each database.

Create and Run a MongoDB Migration Task

Now, you can define and launch the migration task.

In the DMS Console, go to Database migration tasks and click Create task.

Choose a task identifier, and select your previously created replication instance.

For migration type, choose one of the following:

Migrate existing data only

Important: Turn off data validation. This feature is not supported for MongoDB endpoints.

Under Table mappings, click Add new selection rule (you must select at least one) :

Schema: your MongoDB database name (e.g., zips-db)

Source table name: %

Action: Include

Choose to start the task automatically on create.

Once created, the task will begin migrating your data to Amazon DocumentDB. You can monitor progress via the DMS console and view logs for detailed insights.

Wrapping Up

AWS DMS makes migrating from MongoDB to Amazon DocumentDB a simple task. Following the procedures outlined above will help you to reduce downtime and transfer your document-based workloads to a completely controlled environment that grows with your requirements. DocumentDB gives you the AWS security, scalability, and dependability advantages without compromising MongoDB compatibility.

This move can be the next step in developing your architecture if you are thinking about integration with other AWS services, operational simplicity, and long-term maintenance.

How to Set Up AWS EFS Static Provisioning Across Multiple Kubernetes Namespaces

Ismail G. — Fri, 11 Apr 2025 15:57:48 +0000

Bitnami PostgreSQL is a widely-used container image with the default being to run safely as a non-root user. But persistent storage—especially shared storage between environments such as dev and test—becomes a problem. Here in this blog post, I'll walk you through how I used AWS EFS static provisioning to share storage between two namespaces with Bitnami PostgreSQL running on Kubernetes.

Why Static Provisioning?

While dynamic provisioning is easy, static provisioning offers full control. It allows you to set a PersistentVolume (PV) by hand which corresponds with an AWS EFS File System or Access Point—ideal for environments where there are multiple environments (e.g., dev and test). As we’re using static provisioning, there’s no need to define a StorageClass for EFS.

Full control over PersistentVolume (PV) setup.
A way to reuse the same EFS volume across different namespaces.
Simpler debugging for permission or access issues.
No need to define a StorageClass

What We’re Building

A PostgreSQL setup running in two separate namespaces: dev and test

Both environments mount the same EFS volume
PostgreSQL data is shared

Prerequisites

Before you begin:

A running Kubernetes cluster (K3s, EKS, etc.)
An AWS EFS file system already created

Project Structure

Your repo should look like this:
deployment-files/
├── deployment-dev/
│ └── pv-dev.yml, pvc-dev.yml, postgres.yml
└── deployment-test/
└── pv-test.yml, pvc-test.yml, postgres*.yml

My GitLab repo: https://gitlab.com/samueldeniz80/aws-efs-static-provisioning-bitnami-postgresqls/-/tree/main/deployment-files?ref_type=heads

Step 1: Create EFS Access Point

To prevent permission issues when mounting EFS across namespaces, create an Access Point from the AWS Console with:

User ID: 1001
Group ID: 1001
Permissions: 0775

Install EFS CSI Driver in your cluster:

kubectl apply -k "github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.7"

You can also use Helm for EFS CSI Driver installation.

Step 2: Define the PV and PVC

Set your pv’s volumeHandle section with both fs file system id and access point id :

volumeHandle: fs-<file-system-id>::fsap-<access-point-id>

Leave storageClassName empty.

pv-dev.yml:

For pvc also leave storageClassName empty.

pvc-dev.yml:

Create PV and PVC as the same for the test namespace. The test namespace PV will also point to the same access point in the EFS.

Step 3: Configure PostgreSQL Deployment

Make sure the deployment uses fsGroup: 1001 in its securityContext to match EFS Access Point permissions:
securityContext:
fsGroup: 1001

Step 4: Deploy Namespaces

Deploy to dev:

kubectl create namespace dev
kubectl apply -f deployment-files/deployment-dev/ -n dev

Check the logs to verify that the PostgreSQL PV and PVC are bound, and the postgres pod is running.

Deploy to test:

kubectl create namespace test
kubectl apply -f deployment-files/deployment-test/ -n test

Check the logs to verify that the PostgreSQL PV and PVC are bound, and the postgres pod is running.

Outcome

You now have a shared EFS volume accessed by PostgreSQL pods running in different namespaces.

Automate Your Python API with AWS Lambda and EventBridge

Ismail G. — Sun, 23 Mar 2025 07:02:54 +0000

In situations when you want to conduct scheduled tasks without having to worry about the infrastructure, serverless architecture is an excellent option to consider. Over the course of this piece, I will demonstrate how I utilized Amazon Web Services Lambda and Amazon EventBridge to automate a Python-based API update script that runs on a regular schedule.

Use Case

Let's assume you have a website or app that requires you to pull information from a third-party API at regular intervals. The information could be prices, exchange rates, weather, or analytics results. You already have an existing Python script that functions to accomplish this upgrade.

Now, the objective is to execute this script on a regular basis without any need to work with any servers.

Step 1: Create Your Lambda Function

Your Python script needs to be prepared and packaged in such a way that it can be executed by AWS Lambda. This is the first stage.

Your working directory ought to have the following:

.
├── lambda_function.py
├── requirements.txt

lambda_function.py:
When you run a Python script on AWS Lambda, the conventional name assists AWS Lambda in identifying and running your function in the right way. Your primary Python script must be lambda_function.py.

Also you must define lambda_handler(event, context). The lambda_handler() function serves as an entry point for AWS Lambda and will directly be called when your function gets invoked.

requirements.txt:
Requirements.txt contains a list of all the dependencies that your code needs.

After you've structured your folder and written your Lambda function code, the next step is to package your Python script along with its dependencies. AWS Lambda does not automatically install Python packages from requirements.txt — you must include all dependencies in your deployment package:

Install dependencies locally into your project folder:

pip install -r requirements.txt -t .

Create a Deployment Package (ZIP):

zip -r lambda_shopify_update.zip .

Double check that you are zipping up the contents of the folder, not the folder itself. That is important — AWS needs to see the handler file (i.e., the lambda_function.py) in the root of the ZIP file.

Step 2. Upload to AWS Lambda

Now go to the AWS Console:

Open AWS Lambda
Click “Create function”
Choose “Upload from → .zip file”
Upload your lambda_shopify_update.zip
Test your lambda function

Step 3: Automating with EventBridge

Once your Lambda function is working correctly, the next step is to automate its execution using Amazon EventBridge. EventBridge is a serverless scheduler that lets you trigger your Lambda function on a regular schedule.

Go to the Amazon EventBridge section in the AWS Console.
Click “Create rule” to set up an automatic trigger for your Lambda function.
Under Rule type, choose “Schedule” to trigger your function based on time (rather than an event).
Select “Rate-based schedule” to run your Lambda at a regular interval.
Alternatively, you can use “Cron-based schedule” for more specific timing (e.g., every day at 08:00).

In the Target section:
- Choose AWS Lambda.
- Select your deployed Lambda function.
- Click Next.
Review your configuration, and click “Create rule”.

Your Lambda function is now scheduled to run automatically at the interval you defined — no manual execution needed.

Creating an AWS DMS Migration Task

Ismail G. — Sun, 09 Mar 2025 16:23:54 +0000

Migrating Data from Local SQL Server to AWS RDS PostgreSQL Using AWS DMS - II

In my last post, I guided you through building AWS Database Migration Service (DMS) to move data from an on-premises SQL Server to an AWS RDS PostgreSQL database instance. We went over establishing the AWS environment, configuring the source database, and building the required AWS DMS resources.

In this article, we will examine the migration process itself—target. With both source and target endpoints configured, the next step is to create a migration task in AWS DMS.

Creating and Running the AWS DMS Migration Task

With both the source (SQL Server) and target (PostgreSQL) endpoints configured (if not check the Migrating Data from Local SQL Server to AWS RDS PostgreSQL Using AWS DMS - I, it's time to create and execute a migration task.

Creating the Migration Task

1.Navigate to Database Migration Tasks:

Go to AWS DMS Console > Database migration tasks > Create task.

2.Configure Task Settings:

Task Identifier: Just give a name, for example, sqlserver-to-postgres-migration.
Replication instance: Select the replication instance configured earlier.
Source and target database: Choose the previously configured SQL Server source and PostgreSQL target endpoints.
Migration type: Select "Migrate" to perform a full load of the existing data.

3.Task Settings:

Editing mode: Wizard
Target table preparation mode: If you wish DMS to drop and replicate tables on the target, choose for "Drop tables on target". If you wish to maintain the current structure and data unaltered, then choose "Do nothing"; DMS just adds fresh entries without altering or deleting any current data. If you have pre-existing data that ought to be kept whole, this option is handy.
Include LOB columns in replication: Enable this option if your tables contain large object (LOB) data types.
Enable validation: When you enable this option, AWS DMS verifies the row counts and checksums of the source and target databases and confirms that they are equal.

4.Table Mapping and Transformations

Editing mode: Wizard
Selection rules: Define at least one selection rule to specify the schemas and tables you want to be included or excluded from the migration. Use % in the Source table name to include all tables.
Transformation rules (optional): Set transformation rules, if you need to rename schemas, tables, or columns.

5.Premigration assessment

A premigration assessment warns you of potential migration issues before starting your migration task. For this tutorial I skipped premigration assessment.

6.Running the Migration Task

Click Create task, then Start the migration.

AWS DMS will begin extracting data from SQL Server, transforming it, and loading it into PostgreSQL.

Migrating Data from Local SQL Server to AWS RDS PostgreSQL Using AWS DMS - I

Ismail G. — Thu, 27 Feb 2025 09:09:24 +0000

Data migration is an essential activity for those organizations that are moving from on-premises database technology to cloud offerings such as AWS RDS. An extremely helpful service that simplifies this task is the AWS Database Migration Service (DMS). With AWS DMS, for example, you can migrate data from an on-premises Microsoft SQL Server database to an AWS RDS PostgreSQL. I am going to explain the process of creating SQL Server parameters and configuring an AWS DMS replication instance in this post.

Preparing the SQL Server for AWS DMS

Before setting up AWS DMS, it is essential to configure your local SQL Server to allow external connections and ensure proper networking settings.

1. Enabling TCP/IP Connections in SQL Server

By default, SQL Server does not allow remote connections unless TCP/IP is explicitly enabled. Follow these steps to enable TCP/IP connections:

Open SQL Server Configuration Manager.

Navigate to SQL Server Network Configuration → Protocols for MSSQLSERVER.

Locate the TCP/IP protocol and right-click to select Enable.

Right-click on TCP/IP, select Properties, and navigate to the IP Addresses tab.

Under the IPAll section, set TCP Port to 1433 (leave TCP Dynamic Ports blank).

2. Configuring Windows Firewall Rules

After enabling TCP/IP, you need to allow inbound connections on port 1433 through Windows Firewall:

Open Windows Defender Firewall with Advanced Security.

Navigate to Inbound Rules → Add New Rule.

Select Port and click Next.

Choose TCP and enter 1433 in the Specific local ports field.

Click Next.

Choose 'Allow the connection'

Apply the rule to Domain, Private, and Public profiles.

Name the rule and complete the setup.

3. Restarting SQL Server

For the changes to take effect, restart the SQL Server service:

Open SQL Server Configuration Manager.

Select SQL Server Services.

Right-click SQL Server (MSSQLSERVER) and select Restart.

Once the SQL Server settings are configured, test the connection from another computer again using:

sqlcmd -S IP-Address -U Username -P Password

If you can connect successfully, your SQL Server is ready for migration.

Setting Up AWS DMS for Migration

Follow these steps to configure AWS DMS:

1. Creating a Replication Instance

Navigate to the AWS DMS Console.

Select Replication Instances and click Create Replication Instance.

Provide a name and choose an appropriate instance class.

Set the replication instance to public since the SQL Server is hosted on a local computer.

Security Group Configuration

DMS relies on security groups to control inbound and outbound traffic between the replication instance and databases. To properly configure the security group:

Navigate to EC2 Security Groups in the AWS Console.
Locate the security group assigned to the replication instance.
Add the following Inbound Rules:
- MSSQL (TCP/1433): Allow traffic from your local SQL Server’s IP or security group.
- PostgreSQL (TCP/5432): Allow traffic to the target AWS RDS PostgreSQL instance.
Add an Outbound Rule that allows all traffic to leave (egress) the VPC. This ensures communication from the replication instance to the source and target database endpoints.

2. Configuring Source Endpoint (SQL Server)

Choose Source Endpoint and enter SQL Server details.

Set the Endpoint Type to Source.

Enter the Server Name (IP Address), Port (1433), Username, and Password.

Click Test Connection and ensure it succeeds.

3. Configuring Target Endpoint (AWS RDS PostgreSQL)

Navigate to Endpoints and select Create Endpoint.

Choose Target Endpoint and enter AWS RDS PostgreSQL details.

Set the Endpoint Type to Target.

Enter the RDS Endpoint, Port (5432), Username, and Password.

Click Test Connection and verify success.

Database migration tasks

After making those settings you are ready to create a database migration task. I will cover this in my next blog post.