DEV Community: sanjay yadav

Most Teams Don't Move to Amazon RDS for Performance

sanjay yadav — Fri, 29 May 2026 05:19:50 +0000

You’ve decided to move your applications from on-premises to AWS and are looking at the cloud services that best meet your needs. When moving an application with a relational database like Oracle, MySQL, or SQL Server to the cloud, you'll face the choice between Amazon RDS and AWS EC2.

You need to decide whether to:

Use AWS’s Relational Database Service (RDS)
Host a database server on an AWS EC2 (Elastic Compute) instance

What is AWS RDS?

Amazon Relational Database Service (Amazon RDS) is a managed Database-as-a-Service (DBaaS) that helps IT administrators easily set up, run, and scale relational databases in the cloud. RDS supports popular database engines like MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL Server.

When moving to the cloud, most applications using these databases can switch to Amazon RDS without much hassle. You can choose different database instance types based on your needs for CPU, memory, storage, and networking. With Amazon RDS, Amazon takes care of tasks like provisioning, setup, patching, backup, recovery, and failure repair, saving your team from these time-consuming tasks.

Amazon RDS automatically backs up your databases every 24 hours, ensuring that in the worst case, you can recover data for up to 24 hours. With a multi-region active-active strategy, you can achieve near-zero data loss and minimal recovery time. Routine patching is also automated with set maintenance windows for security. On top of this it also supports PITR recovery so you can get back your database to any particular timestamp in last 7 days.

RDS allows you to have read replicas in zones closer to your users, which increases read capacity and reduces the load on production servers by routing read queries to the replicas. You can also send heavy queries to read replicas to lessen the burden on your main servers.

What is Amazon EC2?

Amazon Elastic Compute Cloud (EC2) is a web service that gives you secure access to server instances when you need them. It's easy to get and set up capacity – just use the Amazon EC2 web service interface to add capacity as needed.

You have full control over your computing resources and can scale up or down based on your needs. To provide database services for your application, you can set up EC2 instances and install the necessary database engines yourself.

Next, let’s look at the pros and cons of choosing between Amazon RDS and EC2 for your database.

Administration

When it comes to administration, Amazon RDS is easy to set up because AWS automates the entire process of management, maintenance, and security, allowing you to focus on essential tasks instead of routine maintenance. You can access its capabilities through the AWS Management Console, AWS RDS command-line interface, or simple REST API calls.

AWS EC2 gives you full control over the OS, database version, configuration, and other software components, but you are responsible for all routine maintenance activities, including patches, upgrades, backups, replication, and clustering.

High Availability

Amazon RDS has built-in high availability. It automatically creates a primary database instance and replicates the data to a standby instance in a different Amazon Availability Zone. This ensures that if there is an outage in one zone, you can recover your database from the other zone.

On the other hand, with AWS EC2, you are responsible for configuring the database server in a highly available cluster.

Backups

With Amazon RDS, you can set up automated backups. AWS CloudWatch can notify you about backup failures, completions, and more. You can also get database snapshots on-demand and keep them as long as you need.

With AWS EC2, you have to enable backups yourself and set up separate monitoring to ensure regular backups. You cannot use AWS CloudWatch for this.

Scalability

Amazon RDS easily integrates with Amazon’s scaling tools for both vertical and horizontal scaling. You can scale up to a larger instance in a few clicks, and you can automate the creation of additional read replicas to handle increased read-only workloads.

With AWS EC2, you have to set up a scalable architecture manually, which includes setting up multiple EC2 instances, load balancing, configuring Availability Groups, and Sharding.

Performance

With Amazon RDS, you can configure your instance with a specific number of provisioned IOPS for fast and consistent performance, though it can be expensive. RDS integrates with Amazon CloudWatch for monitoring database performance.

With AWS EC2, you need to choose the right storage volume for the IOPS and latency you need. Since the database server is not AWS-managed, you cannot use AWS CloudWatch for performance monitoring and need to use third-party tools instead.

Storage

With Amazon RDS, you have three storage options:

General-purpose SSD: Cost-effective, delivers single-digit millisecond latencies, and handles up to 3,000 IOPS.
Provisioned IOPS: Ideal for database-intensive workloads needing low latency and very high IOPS throughput.
Magnetic: Supports magnetic storage for backward compatibility.
With AWS EC2, the IOPS and latency depend on the instance type. You can get up to 16,000 IOPS and 2,000 Mbps with the right EBS-optimized instance.

Support and Control

With Amazon RDS, you are limited to the database engines and versions supported by Amazon. Amazon manages upgrades and patches, so you don't handle the database server directly. You have access to database administration tools for necessary tasks.

With AWS EC2, you can install any database engine and version you want, without being limited by AWS's RDS support. You have full control over the operating system and the database server. You can apply updates and patches, set maintenance windows, run multiple instances on the same EC2 instance, and control the ports used.

Security

Amazon RDS offers encryption both at rest and in transit. This means the storage for database instances, read replicas, automated backups, and snapshots are all encrypted while stored.

In AWS EC2, encryption is handled at the EBS volume level, and you can also configure encryption at the database level.

Licensing

Amazon RDS offers both “License Included” and “Bring-Your-Own-License (BYOL)” models, depending on the database engine.

For example, Oracle RDS allows you to bring your license, but Amazon RDS for SQL Server only supports the “License Included” model. You cannot bring your SQL licenses to RDS, as SQL Server is licensed through AWS.

With AWS EC2, you can bring your database licenses regardless of the database engine.

Cost

Spending depends on the instance type, and you can use the AWS Cost Calculator to get detailed costs.

Amazon RDS:

Usually more expensive because Amazon handles routine management tasks for you.

AWS EC2:

Generally cheaper since you manage the database server yourself.
You are responsible for tasks like backup, recovery, patching, and load management.

How to Choose Between AWS RDS and Amazon EC2

Choosing between a database on an EC2 instance and RDS means deciding between managing everything yourself and using a managed service where AWS handles routine tasks. With RDS, a simple API call gives you control over deployment, backups, snapshots, restores, sizing, high availability, and replicas.

In contrast, using EC2 means you need to manually set up, configure, manage, and tune components like EC2 instances, storage, scalability, networking, and security.

Using RDS reduces management overhead and increases flexibility and automation. You can use automated CI/CD systems with AWS CLI, CDK, and CloudFormation to deploy the database with minimal manual work. Managed services let you control the infrastructure and design services that are easy to deploy, replicate, and have auto-healing features.

However, cost is a key factor. Amazon RDS can be slightly more expensive than EC2 for the same configuration. If you have a tight budget or need a database engine or version not supported by RDS, you might have to use an EC2-hosted database.

At KuebOps Consulting, we highly recommend using RDS instances over EC2 for database to our clients. The additional cost that you pay almost always saves a lot more money than what you would spend on managing and scaling the database yourself on an EC2 instance.

Route 53 DNS Firewall: Block Malware Across Your VPC
Fix 504 Errors in GKE Load Balancer (BackendConfig Guide)
How We Use Airflow to Optimize Our DevOps Workflow

Database Performance Discussions Usually Change Once Infrastructure Costs Start Scaling

sanjay yadav — Thu, 28 May 2026 04:47:03 +0000

At smaller scale, managed databases usually feel interchangeable.

The application works.
Queries run.
Everything seems fine.

But once workloads grow and infrastructure costs start increasing, database discussions become much more operational than people initially expect.

Storage performance.
IOPS limits.
Latency.
Cost scaling.

That’s usually where infrastructure tradeoffs start becoming impossible to ignore.

The pricing usually looks straightforward until higher performance tiers start becoming unavoidable.

In practice, performance discussions usually turn into infrastructure efficiency discussions pretty quickly.

I found this benchmark useful because it compares AWS RDS and Civo Postgres from both the performance and operational cost perspective instead of only comparing monthly cost numbers:

https://www.kubeblogs.com/aws-rds-vs-civo-postgres-benchmark/

Kubernetes Observability Usually Gets More Complicated Before It Gets Better

sanjay yadav — Mon, 25 May 2026 05:08:11 +0000

Logs are easy at the beginning.

Production observability usually isn’t.

One pattern that shows up often in Kubernetes environments is teams adding more monitoring components over time and slowly ending up with more complexity than expected.

More agents.
More pipelines.
More moving parts.

Collecting telemetry is usually not the hard part.

Keeping observability systems manageable as infrastructure grows is where things get difficult.

That’s why tooling discussions usually become much more operational than feature comparisons.

Especially once infrastructure starts growing and operational overhead becomes harder to ignore.

I found this breakdown useful because it compares Fluent Bit and Grafana Alloy from a Kubernetes observability perspective instead of treating it as only a tooling comparison:

https://www.kubeblogs.com/fluent-bit-vs-grafana-alloy-kubernetes-observability-2026/

Terraform with AI: Build AWS Infra (Cursor + MCP)

sanjay yadav — Sat, 23 May 2026 05:21:24 +0000

Why Terraform with AI Matters in Modern DevOps

Writing Terraform for anything beyond a small setup quickly becomes tedious.
Once you start dealing with multiple modules, cross-resource dependencies, and AWS-specific quirks, the workflow slows down. Most of the time isn’t spent writing code — it’s spent checking documentation, fixing edge cases, and rerunning terraform apply.
Many teams are now experimenting with Terraform with AI to speed this up.
In practice, that only works partially — unless the AI has proper context.

Build Complete AWS Infrastructure with Terraform MCP Server and Cursor AI - Full Tutorial

How Terraform workflows traditionally worked

A typical workflow looks like this:
Read Terraform docs
Write modules and resources manually
Run terraform plan
Fix errors
Repeat
For small setups, this is manageable.
For production infrastructure, it becomes repetitive and slow. Most engineers end up switching between Terraform registry docs, AWS docs, and their codebase constantly.

Limitations of Using Terraform with AI Without Context

The obvious idea is to use AI to generate Terraform.
In most cases, it starts like this:

“Generate Terraform for a VPC with public and private subnets”
You do get output. But:

It may use outdated arguments
It ignores your module structure
Dependencies are incomplete
It often fails during terraform apply
👉 The core issue: AI does not understand your infrastructure context

Our First Attempt (RAG Failure) (Late 2024 - before advent of modern agents)

To solve this, we built an internal tool using:

Vector database
RAG (Retrieval-Augmented Generation)
The idea was to fetch Terraform documentation and index it in a vector database and provide it to an agent
It helped slightly — but failed in practice:

Iteration was difficult - terraform plan and apply loop - fix errors
Context size limitations
No awareness of project structure
Could not refine outputs
It generated code, but only for simple infrastructure. For complex ones it used to fail after a few iterations.

We didn't try to optimise it further because while we were in middle of it - cursor agents became extremely powerful and they pretty much solved this iteration problem.

What changed with MCP Server + Cursor

The behavior changed once we introduced Terraform MCP Server and used it with Cursor.
Instead of generating code blindly, the system now had access to:

Terraform module documentation
Input/output structures
Resource relationships
The difference was noticeable.
The output was not perfect — but much closer to something usable.

How MCP actually changes the workflow

At a high level, MCP acts as a bridge between the editor (Cursor) and Terraform context.
Instead of guessing, the AI can:

Look up module definitions
Understand required inputs
Follow dependencies across resources

This is the key difference from standard AI usage.

⚙️ What MCP Server Actually Does Internally

The improvement with MCP is not just better prompting — it’s access to structured Terraform knowledge.
The MCP server exposes tools that allow the AI to query real Terraform data:

Key MCP Capabilities:

Provider Documentation Lookup

Fetches full documentation for resources, data sources, and functions

Module Discovery

Finds Terraform modules from the registry with usage examples

Module Details

Retrieves inputs, outputs, and configuration patterns

Policy Search

Helps identify best practices and security policies
👉 In simple terms:
Instead of guessing, the AI can look things up like an engineer would.

Terraform with AI vs Manual vs MCP (Comparison)

In practice, most teams try AI first, then realize that without context, results are unreliable. MCP fixes that gap.

A practical example: building AWS infrastructure

Let’s take a realistic setup:

VPC with public and private subnets
NAT Gateway and Internet Gateway
Application Load Balancer
Auto Scaling group (EC2)
CloudFront distribution
Cloudflare DNS
Jump box for access
This is a typical production-style setup.
Writing this manually takes time — especially when wiring dependencies correctly.

How we approached it

Instead of writing everything manually, we broke the problem into smaller steps and guided the AI.

🧠 Full Prompt Used for Infrastructure Generation

Instead of vague prompts, we used a structured, step-by-step approach to guide the AI.

Start code generation. Do it step by step. Move to next step only after the current step is complete.

Step: Create VPC and Network Infrastructure - use vpc module
- Create VPC with appropriate CIDR block
- Create public and private subnets across 2 AZs
- Set up Internet Gateway
- Configure NAT Gateways in public subnets
- Configure route tables for public/private subnets

Step: Create Security Groups
- ALB security group (allow HTTP/HTTPS inbound)
- EC2 security group 
    - allow traffic from ALB
    - allow ssh from the vpc
- Allow all outbound traffic

Step: Create Auto Scaling Group - use autoscaling module
- Create launch template for EC2 instances
- Use ubuntu ami for the instances
- Configure ASG across private subnets
- Use keypair named "vikas-aws"
- Add a user data script to install nginx and create a simple html page

Step: Create a jumpbox
- Create a jumpbox in the public subnet
- Ensure it has a public IP
- Allow SSH from internet

Step: Create Application Load Balancer - use alb module
- Create ALB in public subnets
- Configure HTTP listener
- Attach to autoscaling group

Step: CloudFront Distribution
- Configure CloudFront with ALB as origin
- Set caching TTL to 0

Step: DNS Configuration
- DNS handled via Cloudflare (no route53)

In practice, breaking the problem into steps like this improves output quality significantly compared to single prompts.

What the generated Terraform looked like

A simplified example:

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

  name = "demo-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1b"]
  public_subnets  = ["10.0.1.0/24", "10.0.2.0/24"]
  private_subnets = ["10.0.3.0/24", "10.0.4.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true
}

This wasn’t perfect out of the box, but:

Structure was correct
Inputs were mostly valid
Dependencies were aligned
That already saves a significant amount of time.

What actually improved (based on usage)

From real usage:

Before:

2–4 hours to assemble infra
Multiple documentation lookups
Several failed applies

After:

Initial setup generated in minutes
Fewer structural errors
Faster iteration
In most teams, the biggest gain is reduced context switching.

Operational considerations

This approach still requires discipline:

Always run terraform plan
Review changes carefully
Do not trust generated code blindly
IAM policies and security configurations must always be reviewed manually.

When Terraform with AI Works Best

In most teams, this approach works well when:

You are building new infrastructure
You need to scaffold modules quickly
You want to reduce repetitive work
It is less effective when used blindly or without validation.

When not to use this approach

Avoid relying on it when:

Infrastructure requires strict compliance
You don’t understand the generated code
You need deterministic, audited configurations
This is not a replacement for Terraform expertise.

Where this fits in a DevOps workflow

This approach integrates naturally with:

Git-based workflows
CI/CD pipelines
Infrastructure reviews
The deployment process does not change — only the way code is written.

FAQ

What is Terraform with AI?

Terraform with AI refers to using AI tools to generate and manage infrastructure code more efficiently.

What is Terraform MCP Server?

It provides AI tools with Terraform context, including modules and documentation.

Is AI-generated Terraform safe for production?

Yes, but only after proper validation and review.

Conclusion

Terraform itself hasn’t changed.
What’s changing is how engineers interact with it.
Using Terraform with AI + MCP Server reduces friction in writing infrastructure — especially for repetitive setups.
It doesn’t replace engineering judgment, but it does make the workflow more efficient.

K3s vs Kubernetes (K8s): Performance, Architecture, Use Cases and When to Choose Each

sanjay yadav — Fri, 22 May 2026 04:50:47 +0000

K3s and Kubernetes (K8s) are often compared, but they are not direct competitors. They solve different infrastructure problems.
K3s can run in under 200MB of RAM, while a standard Kubernetes cluster can exceed 800MB. This makes the choice highly dependent on your environment and workload.

This guide explains the key differences between K3s and Kubernetes, focusing on architecture, performance, and real-world DevOps use cases.

What is Kubernetes (K8s)

Kubernetes is a container orchestration platform designed to manage large-scale distributed systems.
It provides:

Automated deployment and scaling
Self-healing infrastructure
Service discovery and load balancing
Kubernetes is widely used in production environments where scalability and reliability are critical.

What is K3s

K3s is a lightweight Kubernetes distribution designed for environments with limited resources.

It simplifies Kubernetes by:

Packaging components into a single binary
Using lightweight storage (SQLite by default)
Reducing operational complexity
K3s is commonly used in edge computing, IoT, and development environments.

K3s vs Kubernetes: Key Differences

K3s vs Kubernetes Architecture Comparison

K3s vs Kubernetes Performance Comparison

From practical testing, K3s consistently performs better on small instances (1–2GB RAM), while Kubernetes starts showing its strength as workload complexity and scale increase.

Real-World Observation

In a test cluster:

K3s used approximately 200MB RAM
Kubernetes used more than 800MB RAM
K3s performs better in constrained environments, while Kubernetes handles high-scale workloads more effectively.

K3s vs Kubernetes Use Cases

When to Use K3s

Edge computing
IoT deployments
CI/CD environments
Local development

When to Use Kubernetes

Production systems
Microservices architecture
Multi-cloud deployments
High-traffic applications
A common mistake is adopting full Kubernetes too early. For many small projects or internal tools, K3s can handle the workload with significantly less operational overhead.

Decision Guide

Installation Examples

K3s Installation

curl -sfL https://get.k3s.io | sh -

Kubernetes Installation (kubeadm)

kubeadm init
Pros and Cons

K3s

Pros

Lightweight
Fast setup
Low resource usage

Cons

Limited scalability
Fewer enterprise features

Kubernetes

Pros

Highly scalable
Rich ecosystem
Production-grade

Cons

Complex setup
Higher resource usage

FAQ

Is K3s production ready

K3s is production ready for lightweight workloads, especially in edge and constrained environments.

Is K3s faster than Kubernetes

K3s has faster startup time and lower resource consumption compared to standard Kubernetes.

Can K3s replace Kubernetes

K3s is not a replacement for Kubernetes in enterprise environments. It is designed for specific use cases like edge and development.

Continue learning with these in-depth guides:
Kubernetes Architecture Deep Dive (Components Explained)
K8s vs Docker: Complete Comparison Guide
Best Kubernetes Monitoring Tools for DevOps

Conclusion

There is no one-size-fits-all choice here, but in most early-stage or resource-constrained setups, K3s is often the more practical starting point.
K3s and Kubernetes are designed for different types of environments, and choosing the right one depends on your specific use case.
K3s is ideal for lightweight workloads, edge computing, and development environments where simplicity and low resource usage are important.
Kubernetes, on the other hand, is built for large-scale, production-grade systems that require high availability, scalability, and a mature ecosystem.
In most modern DevOps workflows, both are used together:

K3s for development, testing, and edge deployments
Kubernetes for production and high-scale applications
Selecting the right platform is less about features and more about aligning with your infrastructure needs and long-term scalability goals.

Jenkins or GitHub Actions? Deciding the Right CI/CD Tool for Your Workflow

sanjay yadav — Thu, 21 May 2026 05:27:22 +0000

Introduction

Continuous Integration and Delivery is a key part of any software application. Be it a mobile app, a backend app or a website - everything requires CI/CD to make things easier for everyone. From testing and building code to deploying it across environments, CI/CD tools help simplify workflows, reduce manual tasks, and maintain consistency across the development process.

There are tons of options available in the market when it comes to CICD. Among the many available, Jenkins and GitHub Actions stand out as two of the most popular and effective options. Jenkins has been there for a very long time, is mature and is being used by thousands of teams across the globe.

On the other hand, GitHub Actions is designed to work naturally within GitHub, is comparatively newer and is tightly bound to Github (which can be a deal breaker for some folks).

While both are great - which one do you choose? At KubeNine we are inclined towards Github Actions and we’ll tell you why!

What is Jenkins?

Jenkins is a widely used open-source automation server that helps developers build, test, and deploy applications efficiently. For over a decade, it has been a cornerstone of CI/CD workflows, providing teams with the tools needed to automate repetitive tasks.

Supported by a massive community, Jenkins offers an extensive plugin library with over 1,800 plugins, allowing it to integrate with a wide range of open-source and enterprise tools to handle diverse automation needs.

Despite the rise of CI/CD tools like GitLab CI and GitHub Actions, Jenkins is a popular choice among organizations due to its flexibility and extensive capabilities.

According to the Developer Ecosystem Report, 54% of developers rely on Jenkins for their CI/CD needs, showcasing its enduring relevance in the industry.

Below is the architectural diagram of Jenkins:

What is GitHub Actions?

GitHub Actions is an automation tool built directly into GitHub, allowing developers to create workflows for building, testing, and deploying applications.

It simplifies the process of setting up Continuous Integration (CI) and Continuous Delivery (CD) by using YAML-based configuration files stored in the same repository as the code. Also, its completely managed so the users do not have to worry about setting up and managing any instance. This makes it particularly attractive.

One of the key strengths of GitHub Actions is its flexibility. Developers can choose from a vast marketplace of pre-built actions that connect with various tools and services, enabling efficient automation without needing to start from scratch.

GitHub Actions is quickly gaining popularity in the CI/CD space. According to the Developer Ecosystem Report, 51% of developers use GitHub Actions regularly for CI/CD tasks, making it the second most widely adopted tool after Jenkins. Its adoption is especially prominent in personal projects, where 37% of developers rely on it. The simplicity of its setup and its native connection with GitHub repositories make it a go-to choice for many developers and small teams.

GitHub Actions also plays a significant role in the Software Development Life Cycle (SDLC) by automating repetitive tasks like testing and deployment. This not only saves time but also helps developers maintain focus on coding.

Below is the architectural diagram of GitHub Actions, which shows how it operates in a CI/CD pipeline setup:

Building and Pushing a Docker Image: Jenkins vs. GitHub Actions

Let’s walk through the process of setting up a pipeline for both Jenkins and GitHub Actions to build a Docker image and push it to a Docker repository. By comparing the steps, we can better understand the ease of use, setup complexity, and overall user experience.

Setting Up Jenkins: Build and Push Pipeline

We will use Helm to install Jenkins on a Kubernetes cluster and create a pipeline for building and pushing a Docker image.

Steps to Install and Configure Jenkins:

Install Jenkins Using Helm

Add the Jenkins Helm repository:

helm repo add jenkins https://charts.jenkins.io helm repo update

Install Jenkins on your Kubernetes cluster:

helm install jenkins jenkins/jenkins --namespace jenkins --create-namespace

Retrieve the admin password:

kubectl exec --namespace jenkins -it svc/jenkins -c jenkins -- /bin/cat /run/secrets/chart-admin-password

Access Jenkins at http://:8080 and log in using the admin credentials.

Install Required Plugins

Go to Manage Jenkins > Plugins and install the required plugins, such as Pipeline and Docker Pipeline.

Set Up Docker on Jenkins Node

Ensure Docker is installed on the Jenkins agent node.
Add the Jenkins user to the Docker group:

sudo usermod -aG docker jenkins

Create a Pipeline for Docker Build and Push

In Jenkins, create a new Pipeline item.
Add the following script to your pipeline configuration (replace placeholders with your values):

pipeline {
    agent any
    environment {
        DOCKER_USERNAME = credentials('docker-username')
        DOCKER_PASSWORD = credentials('docker-password')
    }
    stages {
        stage('Checkout') {
            steps {
                git url: 'https://github.com/your-username/your-repo.git'
            }
        }
        stage('Build Docker Image') {
            steps {
                sh 'docker build -t your-username/your-image:latest .'
            }
        }
        stage('Push to Docker Hub') {
            steps {
                sh 'docker login -u $DOCKER_USERNAME -p $DOCKER_PASSWORD'
                sh 'docker push your-username/your-image:latest'
            }
        }
    }
}

Run the Pipeline

Save the pipeline and click Build Now to execute the steps. Jenkins will:
Pull the source code from your repository.
Build a Docker image.
Push the image to your Docker repository.

Setting Up GitHub Actions: Build and Push Workflow

GitHub Actions makes it easier to define workflows directly in the repository using YAML files.

Steps to Configure GitHub Actions:

Add a Workflow File

In your repository, create a folder .github/workflows if it doesn’t exist.
Add a file named docker-build-push.yml.

Define the Workflow

Add the following workflow to the file (replace placeholders with your values):

name: Build and Push Docker Image

on:
  push:
    branches: [ "main" ]

jobs:
  build-and-push:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repository
        uses: actions/checkout@v2

      - name: Log in to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Build and Push Docker Image
        run: |
          docker build -t your-username/your-image:latest .
          docker push your-username/your-image:latest

Add Secrets

Go to your repository’s Settings > Secrets and variables > Actions.
Add two secrets:

DOCKER_USERNAME (your Docker Hub username)
DOCKER_PASSWORD (your Docker Hub password)

Commit and Push Changes

Push your changes to the main branch.
GitHub Actions will automatically run the workflow, building the Docker image and pushing it to Docker Hub.
From a practical perspective and based on our experience, we’ve worked extensively with both Jenkins and GitHub Actions, offering services to set up and manage both tools for different teams and projects. What we’ve observed is that there’s nothing wrong with choosing either tool—it all comes down to your unique requirements. The question is:

Which One Is Better: Jenkins or GitHub Actions?

There’s no such thing as a universally “better” tool in the world of CI/CD. However at KubeNine we are inclined more towards Github Actions. The right choice entirely depends on your team’s requirements, project scale, and infrastructure needs

When Jenkins Might Be the Better Option

Jenkins is ideal if you need a self-hosted solution where everything is completely under your control. You can install Jenkins from scratch and configure it to suit your exact requirements.

It has a rich ecosystem of over 1,800 plugins, allowing integration with countless tools and services. Whether you need advanced pipeline customization, on-premises hosting, or compliance with strict organizational policies, Jenkins gives you the flexibility to achieve it all.

However, it’s worth noting that the support for plugins in Jenkins has seen a decline in recent years.

Some plugins are not actively maintained, and keeping them updated can become a challenge. Additionally, the manual setup and maintenance required for Jenkins can be time-consuming, especially for teams that are new to CI/CD.

When GitHub Actions Might Be the Better Option

GitHub Actions is a great choice if you’re looking for something simple and fast. Unlike Jenkins, it doesn’t require a complex setup process. As we demonstrated in the pipeline example above, all you need is a YAML file in your repository.

You simply define the steps, like building a Docker image or running tests, and GitHub handles the rest for you.

For instance, in our example, setting up a pipeline in GitHub Actions was as easy as writing a few lines of YAML. Want to build a Docker image? Just add one line to specify the Docker build action.

Need to push the image to Docker Hub? Add another action for Docker login and push. It’s all optimized for simplicity and speed, making it especially appealing for small to medium-sized teams or personal projects.

If you need more control, GitHub Actions also supports self-hosted runners. This allows you to host your workflows on dedicated virtual machines or servers, ensuring enhanced security and compliance.

For example, in sensitive environments like banking or healthcare, where dedicated VMs are required for better isolation and control, self-hosted runners provide a strong alternative to Jenkins.

Key Considerations:
Factor

Jenkins

GitHub Actions

Ease of Use

Requires manual setup and maintenance, making it more complex for new users.

Minimal setup; simple YAML-based workflows that are ready to use out of the box.

Infrastructure Control

Fully self-hosted; everything from updates to security patches is in your hands.

Offers GitHub-hosted runners for convenience but also supports self-hosted runners for more control.

Security

Full control over servers, suitable for environments with strict compliance requirements.

Self-hosted runners provide similar security, while GitHub-hosted runners are maintained by GitHub.

Customization

Highly customizable with plugins and Groovy pipelines, but requires expertise to configure.

Simple to customize using pre-built actions or by creating your own custom actions.

Speed and Simplicity

Slower setup due to manual configurations and plugin management.

Faster setup; optimized for GitHub-hosted repositories with minimal effort required.

Final Thoughts

Choose Jenkins if:
You require complete control over your CI/CD environment.
Your workflows are highly complex and need extensive customization.
Your organization has the infrastructure to maintain Jenkins servers and manage plugin updates.
Choose GitHub Actions if:
You want a quick and straightforward CI/CD solution.
Your projects are hosted on GitHub, and you prefer everything in one ecosystem.
You’re looking for a scalable solution without the burden of managing infrastructure.

Do You Really Need to Switch from Jenkins to GitHub Actions?

Github Actions might look cool and enticing but don’t switch to just because it looks cool. If your CI/CD pipelines are already fully set up in Jenkins, running smoothly, and your team is comfortable with the tool, there’s no strong reason to switch just for the sake of it. Based on what we’ve discussed so far, such a move may be unnecessary and could lead to additional effort without significant benefits.

However, if you’re starting fresh—whether in a new company or a new project—and your code is hosted on GitHub, GitHub Actions becomes an obvious choice. It’s easy to set up, integrates natively with GitHub repositories, and provides modern features that align well with today’s DevOps workflows. For teams just getting started, GitHub Actions is undoubtedly the more convenient and efficient option.

Ultimately, the need to switch depends on your specific situation. If Jenkins is working well for your team, stick with it. But if you’re looking for a simpler, GitHub-centric solution for new projects, GitHub Actions is the way to go.

Are There Alternatives to Jenkins and GitHub Actions?

Yes, there are several other CI/CD tools available, each designed for different workflows and requirements. Here are four popular alternatives:

1. GitLab CI/CD

Built into GitLab, this tool helps automate builds, tests, and deployments for projects hosted on GitLab.

2. Azure DevOps Pipelines

Microsoft’s CI/CD solution that integrates well with Azure services and supports multiple repositories.

3. CircleCI

A cloud-based CI/CD tool known for its simplicity and support for Docker-based workflows.

4. Bitbucket Pipelines

Atlassian’s CI/CD solution for Bitbucket repositories, tightly integrated with other Atlassian tools.

Frequently Asked Questions

1. Which is better: Jenkins or GitHub Actions?

It depends on your use case. Jenkins is more flexible and customizable for complex CI/CD pipelines, while GitHub Actions is easier to set up and integrates seamlessly with GitHub repositories.

2. Is Jenkins outdated compared to GitHub Actions?

No, Jenkins is still widely used in production environments. However, GitHub Actions is gaining popularity due to its simplicity and native GitHub integration.

3. When should I use GitHub Actions instead of Jenkins?

Use GitHub Actions if you want:

Quick setup
Tight GitHub integration
Minimal maintenance
It’s ideal for small to medium projects.

4. When is Jenkins a better choice than GitHub Actions?

Jenkins is better when you need:

Advanced customization
Complex pipelines
On-premise CI/CD setup

Conclusion

Choosing the right CI/CD tool depends entirely on your team’s requirements and project needs. Both Jenkins and GitHub Actions have unique strengths—Jenkins offers unmatched control and customization, while GitHub Actions provides simplicity and speed, especially for GitHub-hosted projects.

Along with alternatives like GitLab CI/CD, Azure DevOps Pipelines, CircleCI, and Bitbucket Pipelines, there are plenty of options to fit various workflows.

At Kubenine, we provide services to help you set up infrastructure, automate CI/CD pipelines, and manage cloud-native environments.

Our mission is to handle these technical complexities so you can focus entirely on your product. Whether you need a Jenkins-based solution, GitHub Actions workflows, or support with other tools.

Managing Terraform State Locking in S3 Without DytnamoDB

sanjay yadav — Wed, 20 May 2026 05:38:33 +0000

Introduction

If you’ve worked with Terraform, you’ve probably followed the standard setup:

S3 for storing Terraform state
DynamoDB for state locking
It’s widely recommended, and most teams implement it without questioning why.

But Terraform has evolved.

Today, Terraform S3 backend locking can handle state locking without DynamoDB. This introduces a simpler alternative — but also raises an important question:

Do you actually need DynamoDB for Terraform state locking anymore?
In this guide, we’ll break this down from a real-world DevOps perspective — not just configuration, but actual decision-making.

What is Terraform State Locking

Terraform state is the single source of truth for your infrastructure.

Whenever you run terraform apply, Terraform reads and updates this state file.

Without proper state locking:

Multiple users or pipelines can run changes at the same time
State files can become corrupted
Infrastructure becomes inconsistent
Terraform state locking ensures that only one operation modifies the state at a time.

How Terraform Locking Works

At a high level:

Terraform attempts to acquire a lock
If a lock exists → execution stops
If no lock exists → execution proceeds
After completion → lock is released

The difference is in implementation:

Terraform DynamoDB locking

→ lock stored as a database record

Terraform S3 backend locking

→ lock stored as a .tflock file

Terraform S3 Backend Architecture

In a typical Terraform S3 backend setup:

Terraform CLI interacts with the S3 bucket
Reads terraform.tfstate (state file)
Creates .tflock file to acquire a lock
Executes infrastructure changes
Deletes the lock after completion
This removes the dependency on DynamoDB entirely.

Terraform S3 Locking (Modern Approach)

Using Terraform S3 backend locking without DynamoDB simplifies your infrastructure.

Key Benefits

No additional AWS service required
Lower operational cost
Easier setup and maintenance
Faster onboarding for teams
For small teams and low-concurrency environments, this approach works well.

Terraform DynamoDB Locking (Traditional Approach)

The traditional setup uses DynamoDB for Terraform state locking.

Why DynamoDB Was Used

Strong consistency guarantees
Better handling of concurrent operations
Automatic lock management
This makes DynamoDB more reliable in complex or high-scale environments.

S3 vs DynamoDB Locking (Key Differences)

When to Use Terraform S3 Locking

Use Terraform S3 backend locking without DynamoDB if:

You have a small team
Infrastructure changes are controlled
CI/CD pipelines are not running in parallel
You want to reduce cost and complexity This approach is ideal for startups and smaller environments.

When NOT to Use S3 Locking

Avoid S3-only locking in the following scenarios:

High Concurrency CI/CD Pipelines

Multiple pipelines running simultaneously can create conflicts.

Large Teams

More engineers increase the risk of concurrent operations.

Production-Critical Systems

Critical infrastructure requires stronger consistency guarantees.

In these cases, Terraform DynamoDB locking is the safer option.

Real-World Failure Scenario

One common issue with S3 locking occurs when Terraform crashes before releasing the lock.

What Happens

The .tflock file remains in S3
All future Terraform runs fail

Fix

aws s3 rm s3://your-bucket/path/.tflock

This manual cleanup is something every team using S3 locking should be prepared for.

Best Practices for Terraform S3 Backend

To safely use Terraform S3 backend locking, follow these best practices:

Enable S3 versioning to protect state
Use KMS encryption for security
Separate state files for each environment
Restrict IAM permissions (least privilege)
Monitor state access and changes

Migration from DynamoDB to S3 Locking

Migrating from DynamoDB to S3 locking is straightforward.

Step 1: Enable Locking

use_lockfile = true

Step 2: Migrate State

terraform init -migrate-state

Step 3: Validate

Test concurrency scenarios before using this setup in production.

Decision Guide

If you're unsure which approach to choose, use this simple rule:

Small team → S3 locking
Low concurrency → S3 locking
Large team → DynamoDB locking
High CI/CD activity → DynamoDB locking

FAQ

Is DynamoDB required for Terraform state locking?

No, Terraform S3 backend locking can replace DynamoDB in many cases.

Is Terraform S3 locking safe for production?

Yes for small setups, but not ideal for high-concurrency environments.

What is the biggest risk of S3 locking?

Concurrency issues and stuck .tflock files.

If you're working on Terraform and cloud automation, you might also find these useful:

https://www.kubeblogs.com/gcp-billing-kill-switch-with-terraform/
https://www.kubeblogs.com/fluent-bit-vs-grafana-alloy/
https://www.kubeblogs.com/how-civo-kubernetes-routes-pod-traffic/

Conclusion

Terraform S3 backend locking provides a simpler alternative to DynamoDB.

For small and medium setups, it reduces complexity and cost significantly.

However, for high-scale environments with frequent concurrent deployments, DynamoDB remains the more reliable option.

The key is choosing the right approach based on your workload — not blindly following defaults.

How to Avoid GitHub Token Rate Limiting Issues | Complete Guide for DevOps Teams

sanjay yadav — Tue, 19 May 2026 05:05:03 +0000

Introduction

Your CI/CD pipeline was working fine until suddenly every build started failing with a GitHub API 403 error.

I faced this exact issue during a production deployment. Everything looked fine—no code changes, no infrastructure issues—but pipelines kept failing.

At first, we thought it was a bug in the pipeline, but nothing pointed to the actual issue.

After debugging for hours, it became clear that the problem was not the code, but GitHub API rate limiting.

If you are facing GitHub API rate limit exceeded errors in CI/CD pipelines, this guide will help you fix them effectively.

Quick Fix (TL;DR for busy DevOps engineers): Use authenticated tokens, reduce unnecessary API calls, implement caching, and switch to GitHub Apps for scalable systems.
What is GitHub API Rate Limiting?
GitHub API rate limiting restricts how many API requests you can make within a specific time window. This ensures fair usage and prevents abuse.

In real-world DevOps workflows, this limit can quickly become a bottleneck.

Why GitHub API Rate Limit Errors Happen in CI/CD

In most DevOps setups, pipelines frequently interact with GitHub APIs:

Fetching repositories
Triggering workflows
Checking build statuses
Managing pull requests
Common causes include:

Frequent API polling
Multiple services making requests at the same time
Unauthenticated API usage
This is where GitHub API rate limit exceeded errors typically occur.

GitHub API Rate Limits Explained (Token Types)

Unauthenticated Requests: 60 requests per hour
Personal Access Token (PAT): 5000 requests per hour
GitHub Actions Token: approximately 1000 requests per hour
Using authenticated requests significantly increases your available limits.

Token Management Strategies

Use GitHub Apps Instead of Personal Tokens
GitHub Apps provide higher rate limits and better security.

# .github/workflows/deploy.yml
name: Deploy with GitHub App
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          token: ${{ secrets.GITHUB_APP_TOKEN }}

      - name: Deploy
        run: |
          # Your deployment logic here

Implement Token Rotation

Rotate tokens regularly to avoid hitting limits:

#!/bin/bash
# token-rotation.sh
OLD_TOKEN=$1
NEW_TOKEN=$2
# Update secrets in repository
gh secret set GITHUB_TOKEN --body "$NEW_TOKEN"

Use Repository-Specific Tokens

Different tokens for different purposes

env:
DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
NOTIFY_TOKEN: ${{ secrets.NOTIFY_TOKEN }}
BACKUP_TOKEN: ${{ secrets.BACKUP_TOKEN }}

Rate Limit Handling in Code

Implement Exponential Backoff

This function retries API calls when rate limits are hit.

import time
import random
from functools import wraps

def retry_with_backoff(max_retries=3, base_delay=1):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(max_retries):
                try:
                    return func(*args, **kwargs)
                except Exception as e:
                    if "rate limit" in str(e).lower() and attempt < max_retries - 1:
                        delay = base_delay * (2 ** attempt) + random.uniform(0, 1)
                        time.sleep(delay)
                        continue
                    raise
            return None
        return wrapper
    return decorator

@retry_with_backoff(max_retries=5, base_delay=2)
def make_github_request(url, headers):
    response = requests.get(url, headers=headers)
    if response.status_code == 429:
        retry_after = int(response.headers.get('Retry-After', 60))
        time.sleep(retry_after)
        raise Exception("Rate limited")
    return response

Check Rate Limit Headers

Always monitor rate limit headers in your requests:

def check_rate_limit(response):
    remaining = int(response.headers.get('X-RateLimit-Remaining', 0))
    reset_time = int(response.headers.get('X-RateLimit-Reset', 0))

    if remaining < 100:  # Warning threshold
        print(f"Warning: Only {remaining} requests remaining")
        print(f"Rate limit resets at: {reset_time}")

    return remaining, reset_time

GitHub API Rate Limit Architecture (CI/CD Flow)

CI/CD Pipeline Optimization
Batch API Requests
Combine multiple operations into single requests:

# Instead of multiple individual requests
- name: Get PR details
  run: |
    # Bad: Multiple API calls
    gh pr view ${{ github.event.pull_request.number }} --json title
    gh pr view ${{ github.event.pull_request.number }} --json body
    gh pr view ${{ github.event.pull_request.number }} --json files

    # Good: Single API call
    gh pr view ${{ github.event.pull_request.number }} --json title,body,files

Cache API Responses

Use GitHub Actions cache to reduce API calls:

``- name: Cache API response
uses: actions/cache@v3
with:
path: ~/.cache/github-api
key: ${{ runner.os }}-api-cache-${{ github.sha }}
restore-keys: |
${{ runner.os }}-api-cache-

name: Use cached data run: | if [ -f ~/.cache/github-api/data.json ]; then echo "Using cached data" else echo "Fetching fresh data" gh api repos/${{ github.repository }}/commits > ~/.cache/github-api/data.json fi`

Optimize Workflow Triggers

Reduce unnecessary workflow runs:

Only run on specific paths

on:
push:
branches: [main]
paths:
- 'src/'
- 'package.json'
- '.github/workflows/'

Skip workflows for draft PRs

name: Skip for draft PRs if: github.event.pull_request.draft == true run: exit 0

Monitoring and Alerting

Set Up Rate Limit Monitoring

name: Monitor rate limits
run: |
response=$(gh api rate_limit)
remaining=$(echo $response | jq '.rate.remaining')

if [ $remaining -lt 100 ]; then
echo ":⚠️:Rate limit low: $remaining requests remaining"
fi
`

Create Rate Limit Dashboard

`
import requests
import json
from datetime import datetime

def monitor_rate_limits(token):
headers = {'Authorization': f'token {token}'}
response = requests.get('https://api.github.com/rate_limit', headers=headers)

data = response.json()
rate = data['rate']

print(f"Remaining: {rate['remaining']}")
print(f"Reset time: {datetime.fromtimestamp(rate['reset'])}")

if rate['remaining'] < 100:
    # Send alert to Slack/Teams
    send_alert(f"GitHub rate limit low: {rate['remaining']} remaining")

GitHub Token Types Comparison

Choosing the right authentication method directly impacts pipeline stability.

What Happens When Rate Limit is Exceeded?

Best Practices Summary

Use GitHub Apps for higher rate limits
Implement exponential backoff
Monitor API headers
Cache API responses
Batch API requests
Optimize workflows
Rotate tokens regularly

If you are working with cloud and DevOps setups, these guides may help:

https://www.kubeblogs.com/k3s-vs-kubernetes/
https://www.kubeblogs.com/aws-t2-vs-t3-vs-t4g/
https://www.kubeblogs.com/aws-gp2-vs-gp3/
https://www.kubeblogs.com/s3-security-best-practices/

FAQ:

What is GitHub API rate limiting?

GitHub API rate limiting restricts how many API requests you can make within a defined time window.

Why do I get a 403 error in GitHub API?

You get a 403 error when you exceed your API rate limit or use unauthenticated requests.

How can I fix GitHub API rate limit exceeded errors?

Use authenticated tokens, reduce unnecessary API calls, and implement caching strategies.

Can GitHub Actions hit rate limits?

Yes, GitHub Actions can hit rate limits, especially in workflows that make frequent API calls.

Conclusion

GitHub API rate limiting is a common issue in DevOps workflows, but it is predictable once you understand how it works.

By using authenticated tokens, reducing API calls, implementing caching, and leveraging GitHub Apps, you can prevent unexpected failures in your CI/CD pipelines.

Handling API limits properly is essential for building stable and scalable automation systems.

The Simplest AWS Security Hack I've Shipped in a Decade

sanjay yadav — Mon, 18 May 2026 07:02:29 +0000

DNS based firewalls are one of the easiset and fastest ways to secure your network. They have been around for decades and have been widely adopted for network security. They simply block DNS queries to malicious domains before they can even start to communicate with the internet.

When I work with our customers, I often find out that they implement all sorts of security controls like security groups, network policies, etc. but they almost always miss out on the simplest and most effective one - DNS based firewalls. DNS based firewalls are not a replacement for these other controls, but they are a powerful addition.

AWS has a very simple mechanism to achieve this on your VPC DNS resolver. It's called Route 53 Resolver DNS Firewall. It's a simple rule based firewall that sits in front of the DNS resolver your VPC already uses. When something inside the VPC asks "where is evil-c2.ru?", the firewall checks the domain against AWS's managed threat lists and returns NXDOMAIN if it's bad. The connection dies before a single packet leaves the network. That's the whole idea. Nothing runs on the host. Nothing sits in the packet path. No application has to change. It covers every EC2, Fargate task, Lambda, and EKS pod in the VPC the moment you turn it on, and most setups cost under $30 a month.

I've been in platform work for almost a decade now. I have never seen a security primitive with this effort-to-outcome ratio. AWS shipped it in 2021. Very few teams I have audited run it.

What you actually ship - a Terraform module

You create five things:

A rule group pointing at AWS's four managed threat lists: AWSManagedDomainsMalwareDomainList, AWSManagedDomainsBotnetCommandandControl, AWSManagedDomainsAmazonGuardDutyThreatList, AWSManagedDomainsAggregateThreatList
A rule group with your own policy-forbidden domains (webhook.site, transfer.sh, pastebin mirrors, crypto miners)
Rule group associations to each VPC you want covered
A Resolver query log config writing every DNS query to CloudWatch
A metric filter, alarm, and SNS topic for notifications on blocked queries Under 200 lines of Terraform.

Terraform implementation

Here's the shape of it:

`
data "aws_route53_resolver_firewall_domain_list" "botnet" {
name = "AWSManagedDomainsBotnetCommandandControl"
}

resource "aws_route53_resolver_firewall_rule_group" "managed" {
name = "managed-threat-blocks"
}

resource "aws_route53_resolver_firewall_rule" "botnet" {
name = "block-botnet-c2"
firewall_rule_group_id = aws_route53_resolver_firewall_rule_group.managed.id
firewall_domain_list_id = data.aws_route53_resolver_firewall_domain_list.botnet.id
priority = 10
action = "BLOCK"
block_response = "NXDOMAIN"
}

resource "aws_route53_resolver_firewall_rule_group_association" "managed" {
firewall_rule_group_id = aws_route53_resolver_firewall_rule_group.managed.id
vpc_id = var.vpc_id
priority = 101
name = "managed-block"
}

resource "aws_route53_resolver_query_log_config" "vpc" {
name = "vpc-dns-logs"
destination_arn = aws_cloudwatch_log_group.dns.arn
}

resource "aws_route53_resolver_query_log_config_association" "vpc" {
resolver_query_log_config_id = aws_route53_resolver_query_log_config.vpc.id
resource_id = var.vpc_id
}
`
`
Three things to be careful about:

Association priority ordering. Allowlist rule groups need a lower number than blocklists, or the block wins. I use 50 for allow, 101+ for block. The priority lives on the association, not the rule group.
block_response = "NXDOMAIN", not NODATA. NXDOMAIN makes the client fail cleanly. NODATA can leave some resolvers hanging in a retry loop.
Query logging is a separate resource. The firewall decides whether to block. The query log config is what actually writes entries. You need both, and both need VPC associations. ### What you get back, immediately

Malware C2 communication is blocked for every workload, automatically.

EC2, ECS, Fargate, Lambda, EKS pods. Anything using the VPC resolver, which is almost everything by default. When a compromised container tries to phone home to evil-c2.ru, the resolver returns NXDOMAIN. The connection dies at the DNS layer. No packet leaves your VPC.

You get a complete DNS audit trail in CloudWatch.

Every query, every VPC, every source IP. When something goes sideways — supply chain compromise, malicious npm package, leaked credential being abused — you can answer "what did it try to talk to?" in minutes.

You enforce egress policy without asking app teams to do anything
. Want to block webhook.site, transfer.sh, and anonymous file upload services? Add them to a domain list. Done. No config change in any app. No proxy PAC file. No VPN rules.

Safety against DNS-over-HTTPS bypass attempts

DNS Firewall catches DNS-over-HTTPS bypass attempts.

Modern malware increasingly uses DoH to talk to 1.1.1.1, dns.google, or attacker-controlled resolvers, routing around traditional egress proxies that can't see inside TLS. But the first step of DoH is still resolving the DoH endpoint. If that endpoint is in a threat list, the lookup fails before the HTTPS tunnel ever opens.

How do I suggest rolling this out?

Deploy in ALERT mode. Do not enable BLOCK mode in the beginning to avoid unexpected blockages. Wait two weeks. Run this CloudWatch Insights query:


fields query_name, firewall_domain_list_id
| filter firewall_rule_action = "ALERT"
| stats count(*) as hits by query_name
| sort hits desc

Flip to BLOCK one managed list at a time. Start with BotnetCommandandControl (highest confidence, fewest false positives). End with AggregateThreatList (broadest, highest false-positive rate). Wait a week between flips. If something breaks, you know which list did it.

The cost math

For a typical setup:

"It's not a complete egress solution.

" Correct. It doesn't inspect payloads. It doesn't block IP-literal traffic from malware that hardcodes IPs. It doesn't replace security groups or NAT gateways with fixed egress IPs.

However, it's a great addition to your egress security posture. It's a simple and effective way to block malicious domains before they can even start to communicate with the internet.

Frequently Asked Questions

What is Route 53 DNS Firewall?

Route 53 DNS Firewall is an AWS service that filters outbound DNS queries at the VPC resolver level, allowing you to block malicious domains, command-and-control (C2) traffic, and unwanted destinations before any connection is established.

How does Route 53 DNS Firewall work?

Route 53 DNS Firewall evaluates DNS queries against managed and custom domain lists. If a domain is flagged, it returns an NXDOMAIN response, stopping communication before traffic leaves your VPC.

Does Route 53 DNS Firewall require agents?

No, Route 53 DNS Firewall is completely agentless. It works at the VPC DNS resolver level and automatically protects EC2, Lambda, Fargate, and EKS workloads without any application changes.

Can Route 53 DNS Firewall block malware?

Yes, it blocks malware by preventing DNS resolution of malicious domains, including botnet command-and-control servers, using AWS managed threat intelligence lists.

Does Route 53 DNS Firewall support Lambda and EKS?

Yes, it works automatically with Lambda, EKS, EC2, and Fargate as long as they use the default VPC DNS resolver.

What is the cost of Route 53 DNS Firewall?

Pricing depends on DNS query volume and rule groups. Most small to mid-sized setups typically cost between $15 and $70 per month.

Should I enable BLOCK mode immediately?

No, it’s recommended to start in ALERT mode, monitor DNS queries for false positives, and gradually move to BLOCK mode to avoid breaking production workloads.

Conclusion

Route 53 DNS Firewall is one of those rare AWS features that’s simple to set up but makes a real difference. With just a bit of configuration, you can block malicious domains, reduce risk from compromised workloads, and finally get visibility into what your systems are trying to reach outside your VPC.

It’s not meant to replace everything else in your security stack, but it solves a problem that a lot of teams don’t even realize they have—uncontrolled outbound traffic.

If you haven’t tried it yet, start in alert mode, watch what shows up, and then move to blocking step by step. You’ll likely catch things you didn’t expect.

For the effort involved, it’s easily one of the highest-impact security improvements you can make in AWS.

Ship it or get in touch with KubeNine on (https://kubenine.com) to understand it further.

Docker Image Re-Tagging in AWS ECR Is More Inefficient Than Most Teams Realize

sanjay yadav — Fri, 15 May 2026 04:54:55 +0000

At small scale, Docker image tagging feels pretty straightforward.

But once larger CI/CD pipelines and multiple environments get involved, re-tagging images inside AWS ECR starts becoming pretty inefficient.

A lot of teams still:

pull large images locally
re-tag them
push them again

even when the image itself never actually changed.

The inefficient part is that the image itself usually hasn’t changed at all.

In many cases, re-tagging is really just a metadata operation, but traditional workflows still end up moving large image layers around unnecessarily.

At larger scale, this starts becoming less of a Docker problem and more of a CI/CD workflow problem.

That’s usually where API-based workflows or tools like Skopeo start making much more sense for image promotion between environments and registries.

This breakdown explains some practical ways teams handle ECR re-tagging more efficiently:

https://www.kubeblogs.com/docker-image-re-tagging-limitations-aws-ecr-solutions-alternatives-2025/

Host a Static Website on AWS S3 in Minutes

sanjay yadav — Thu, 14 May 2026 07:02:40 +0000

Amazon S3 (Simple Storage Service) lets you host static websites. Static websites are made up of HTML, CSS, JavaScript, and media files — no server-side code is needed.

This guide will walk you through the steps to set up and publish a static website using an S3 bucket.

Step 1: Create an S3 Bucket

Go to the S3 Console in AWS.
Click Create bucket.
Enter a unique name for your bucket. For website hosting, the bucket name should match your domain name (e.g., example.com).
Choose a region.
Uncheck Block all public access (you'll make the bucket public for web access).
Acknowledge the warning and click Create bucket.

Step 2: Upload Your Website Files

Open your new bucket.
Click Upload.
Add your HTML, CSS, JS, and other static files.
Click Upload.

Step 3: Set Permissions to Make Files Public

You need to make your files publicly readable:

Go to the

Permissions tab

.
Scroll to

Bucket Policy

.
Add a policy like this:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket-name/*"
}
]
}

Replace your-bucket-name with the actual name of your bucket.

Step 4: Enable Static Website Hosting

Go to the Properties tab of the bucket.
Scroll to Static website hosting.
Click Edit.
Choose Enable.
Enter the name of your index document (e.g., index.html). You can also add an error document (e.g., error.html).
Save changes.
After saving, you'll see a Bucket website endpoint. This is the URL of your website.

Step 5: (Optional) Use a Custom Domain with Route 53

If you have a domain name, you can use Amazon Route 53 to point it to your S3 site:

Create a hosted zone for your domain.
Add an Alias record pointing to the S3 website endpoint.
Make sure your S3 bucket name matches your domain exactly (e.g., example.com) for this to work.

FAQs

What is Amazon S3 static website hosting?

Amazon S3 static website hosting allows developers to host HTML, CSS, JavaScript, and media files directly from an S3 bucket without managing servers.

Can I host a website on AWS S3 for free?

Yes. Small static websites may fit within the AWS Free Tier limits depending on storage, requests, and bandwidth usage.

Do I need EC2 to host a static website on AWS?

No. Static websites can be hosted directly on Amazon S3 without using EC2 instances or backend servers.

Can I use a custom domain with S3 website hosting?

Yes. You can connect a custom domain using Amazon Route 53 and point it to the S3 website endpoint.

Does Amazon S3 support HTTPS for static websites?

S3 website endpoints do not directly support HTTPS. AWS CloudFront is commonly used to enable HTTPS and CDN support.

Summary

Hosting a static website with Amazon S3 is simple and doesn't require a server. You just upload your files, set public access, and turn on website hosting. You can also link a custom domain if you have one.

Let me know if you need help with custom error pages or adding HTTPS using CloudFront.

Authentication in Kubernetes Gets Complicated Faster Than Most Teams Expect

sanjay yadav — Wed, 13 May 2026 04:37:34 +0000

One thing I keep noticing in Kubernetes environments is how quickly authentication becomes difficult to manage once multiple internal services and dashboards are involved.

At first, exposing applications through Ingress feels straightforward.

But as clusters grow, teams usually end up solving authentication separately for different applications, which slowly turns into duplicated configuration and inconsistent access control across environments.

The part that makes this setup useful is that authentication gets handled closer to the ingress layer instead of inside every application separately.

Using OAuth2 Proxy with NGINX Ingress makes it possible to centralize authentication using providers like GitHub or Google while keeping internal services much simpler.

I came across a useful walkthrough covering this setup here:

https://www.kubeblogs.com/authentication-with-oauth2-proxy-and-nginx-ingress-on-kubernetes/

DEV Community: sanjay yadav

Most Teams Don't Move to Amazon RDS for Performance

What is AWS RDS?

What is Amazon EC2?

Administration

High Availability

Backups

Scalability

Performance

Storage

Support and Control

Security

Licensing

Cost

Amazon RDS:

AWS EC2:

How to Choose Between AWS RDS and Amazon EC2

Read More

Database Performance Discussions Usually Change Once Infrastructure Costs Start Scaling

Kubernetes Observability Usually Gets More Complicated Before It Gets Better

Terraform with AI: Build AWS Infra (Cursor + MCP)

Why Terraform with AI Matters in Modern DevOps

Build Complete AWS Infrastructure with Terraform MCP Server and Cursor AI - Full Tutorial

How Terraform workflows traditionally worked

Limitations of Using Terraform with AI Without Context

Our First Attempt (RAG Failure) (Late 2024 - before advent of modern agents)

What changed with MCP Server + Cursor

How MCP actually changes the workflow

⚙️ What MCP Server Actually Does Internally

Key MCP Capabilities:

Provider Documentation Lookup

Module Discovery

Module Details

Policy Search

Terraform with AI vs Manual vs MCP (Comparison)

A practical example: building AWS infrastructure

How we approached it

🧠 Full Prompt Used for Infrastructure Generation

What the generated Terraform looked like

What actually improved (based on usage)

Before:

After:

Operational considerations

When Terraform with AI Works Best

When not to use this approach

Where this fits in a DevOps workflow

FAQ

What is Terraform with AI?

What is Terraform MCP Server?

Is AI-generated Terraform safe for production?

Conclusion

Related reading

K3s vs Kubernetes (K8s): Performance, Architecture, Use Cases and When to Choose Each

What is Kubernetes (K8s)

What is K3s

K3s vs Kubernetes: Key Differences

K3s vs Kubernetes Architecture Comparison

K3s vs Kubernetes Performance Comparison

Real-World Observation

K3s vs Kubernetes Use Cases

When to Use K3s

When to Use Kubernetes

Decision Guide

Installation Examples

K3s Installation

Kubernetes Installation (kubeadm)

K3s

Pros

Cons

Kubernetes

Pros

Cons

FAQ

Is K3s production ready

Is K3s faster than Kubernetes

Can K3s replace Kubernetes

Read More

Conclusion

Jenkins or GitHub Actions? Deciding the Right CI/CD Tool for Your Workflow

Introduction