Forem: Ravi Kyada

How We Re-Engineered a Production-Grade AI Platform on AWS to Balance Performance and Cloud cost.

Ravi Kyada — Fri, 30 Jan 2026 07:22:35 +0000

Running AI workloads in production is fundamentally different from running traditional web applications. Compute-heavy jobs, unpredictable traffic patterns, large data volumes, and extensive observability requirements can cause cloud costs to grow rapidly — often faster than user adoption.

This case study describes how we helped a client optimize their AWS architecture for a production AI platform , reducing costs significantly while preserving performance, scalability, and reliability.

The Business Problem: Rising AWS Costs Without Matching Growth

The client operates a production AI-based platform on AWS, serving customers through APIs while running background AI processing jobs. Over time, their AWS monthly spend was increasing steadily, but:

User growth was flat
Request volume was stable
No major new features had been launched

Despite a technically sound architecture, cloud costs were becoming a concern for leadership. The goal was not to cut costs at the expense of reliability or slow down the product, but to establish cost-efficient, sustainable operations for AI workloads.

High-Level Overview of the AI Platform

At a high level, the system consisted of:

Public APIs running on AWS compute services
Asynchronous AI jobs for data processing and model inference
Managed databases for transactional and analytical workloads
Object storage for AI artifacts and intermediate data
Extensive logging and metrics for observability and debugging

The platform was designed for scalability and correctness — but cost efficiency had not been revisited since the early growth phase.

Step 1: Cost Analysis and Visibility

The first phase focused on understanding where money was actually being spent.

Actions Taken

Enabled detailed AWS Cost Explorer and Cost and Usage Reports (CUR)
Tagged resources by:
Service
Environment (prod, staging)
Workload type (API, AI jobs, storage, observability)
Analyzed costs across:
EC2, ECS/EKS
RDS and object storage
CloudWatch Logs and metrics
Data transfer between services and regions

Key Findings

Compute resources were over-provisioned for peak traffic that rarely occurred
AI background jobs were running on on-demand instances despite being fault-tolerant
Logging volume had grown linearly with data size, not with actual debugging needs
Cross-AZ and cross-service data transfer costs were non-trivial

This phase established a baseline and ensured optimization decisions were data-driven , not assumption-based.

Step 2: Compute Optimization for APIs and AI Jobs

API Layer

Right-sized EC2/ECS workloads based on real CPU and memory utilization , not instance defaults
Tuned Auto Scaling policies to scale on realistic metrics rather than conservative thresholds
Reduced idle capacity during off-peak hours without affecting latency SLAs

Trade-off: Slightly slower scale-up time during traffic spikes, mitigated by warm capacity buffers.

Background AI Jobs

Migrated suitable workloads to Spot Instances using:
Managed node groups / capacity providers
Job retry logic and checkpointing
Split AI workloads into:
Latency-sensitive (on-demand)
Throughput-oriented (Spot)

Trade-off: Occasional Spot interruptions, handled at the application level with retries and idempotency.

Step 3: Database and Storage Optimization

Databases

Reviewed RDS instance classes and storage performance
Reduced over-provisioned IOPS and instance sizes where utilization was consistently low
Introduced read replicas only where read scaling was actually required
Implemented data lifecycle policies for historical data

Object Storage

Applied S3 lifecycle rules :
Hot data in Standard
Infrequently accessed artifacts moved to IA
Long-term archives moved to Glacier
Removed unused or duplicate AI artifacts accumulated during experimentation

Trade-off: Slightly higher retrieval latency for archived data, acceptable for non-production paths.

Step 4: Logging and Monitoring Cost Reduction

Logging was one of the fastest-growing cost centers.

Improvements Made

Reduced log verbosity for production workloads
Introduced sampling for high-volume API logs
Set retention policies in CloudWatch Logs instead of keeping logs indefinitely
Exported critical logs to S3 for low-cost long-term retention
Reviewed custom metrics and removed unused ones

Outcome: Observability quality remained intact while log storage and ingestion costs dropped substantially.

Step 5: Network Configuration Optimization and Traffic Path Reduction

As the platform scaled, we identified that a meaningful portion of AWS spend was tied to network data transfer rather than raw compute. While the architecture was functionally correct, traffic paths were not always cost- or latency-efficient.

Improvements Implemented

Reviewed service-to-service traffic flows and eliminated unnecessary cross-AZ communication by aligning compute and dependent services within the same Availability Zones where fault tolerance allowed.
Optimized VPC routing and security group design to ensure direct traffic paths and avoid unintended hops through NAT gateways or intermediate services.
Reduced reliance on NAT Gateways by introducing VPC endpoints (Interface and Gateway endpoints) for AWS services such as S3, CloudWatch, and ECR, significantly lowering outbound data transfer costs.
Ensured load balancers, backend services, and databases were regionally and zonally aligned , minimizing cross-zone data transfer charges.
Introduced caching at appropriate layers to avoid repeated network calls for frequently accessed data and AI artifacts.

Engineering Trade-offs

Tighter AZ affinity required careful evaluation of failure scenarios and was balanced with selective multi-AZ redundancy for critical paths.
Additional upfront design effort was needed to map traffic flows, but it resulted in simpler and more predictable network behavior.

Outcome

These changes reduced network data transfer costs while also improving request latency and hop efficiency , leading to faster service-to-service communication and a more predictable networking model under load.

Step 6: Governance and Cost Controls

To prevent cost creep from returning:

Implemented AWS Budgets and alerts
Enforced resource tagging via IaC
Added cost checks to infrastructure review processes
Established periodic cost review cycles alongside performance reviews

This ensured optimisation became an ongoing practice , not a one-time effort.

Results: Measurable Improvement Without Compromise

Without disclosing exact numbers, the outcomes were clear:

Noticeable reduction in overall AWS spend
Improved compute efficiency for AI workloads
Better alignment between traffic patterns and infrastructure scaling
Stable production performance with no reliability regressions
Increased confidence in cost predictability as the platform scales

Most importantly, the platform became cost-efficient by design , not by constant manual intervention.

Conclusion: Sustainable Cost Control for AI Workloads

AI platforms amplify both value and inefficiency in cloud environments. Over-provisioning, excessive logging, and conservative architecture choices can quietly inflate costs if left unchecked.

This case study demonstrates that meaningful AWS cost optimization:

Does not require compromising performance or reliability
Relies on engineering discipline, not shortcuts
Works best when embedded into architecture and governance

Key Takeaway

Sustainable cloud cost optimization for AI products comes from understanding workload behavior, making intentional trade-offs, and continuously aligning infrastructure with real usage — not peak assumptions.

Choosing Between VPC Peering and Transit Gateway: What to Choose, When, and Why

Ravi Kyada — Tue, 27 Jan 2026 05:00:39 +0000

VPC Peering and Transit Gateway are used to connect multiple VPCs.However, the efficiency of these solutions depends on a robust networking infrastructure.

Designing an AWS network can feel like walking a tightrope — one wrong decision can lead to unnecessary costs or an architecture that pulls your system in completely different directions. At first glance, everything seems right.

Every option promises seamless connectivity. Yet a single misstep can result in routing complexity, security blind spots, or expenses that quietly grow over time.

If you’re a cloud engineer, DevOps professional, or architect, chances are you’ve asked yourself this question at least once:

“Should I use VPC Peering or AWS Transit Gateway for my architecture?”

On the surface, both services appear to solve the same fundamental problem — connecting VPCs. But here’s the catch: they solve it in very different ways , and choosing the wrong one can be like building a village road when you actually need a national highway.

AWS doesn’t always make this choice obvious. Documentation explains what each service does, but rarely tells you when one becomes a better option than the other. And that’s where many architectures go wrong — not due to lack of knowledge, but due to lack of contextual decision-making.

Think of it this way:

VPC Peering is like directly shaking hands with someone across the table. Simple, personal, and effective — but limited in reach.

Transit Gateway, on the other hand, is more like setting up a central meeting hall where everyone comes together, follows rules, and communicates in an organized manner.

So the real question isn’t “Which service is better?”

The real question is “Which service fits my current needs and future growth?”

In this article, we’ll unpack that decision step by step. We’ll move beyond definitions and dive into real-world use cases, architectural trade-offs, cost implications, and scaling realities. By the end, you won’t just know the difference between VPC Peering and Transit Gateway — you’ll know exactly when to choose one over the other, and why.

Let’s break it all down — clearly, practically, and without buzzword overload.

## Understanding the Core Problem

Before choosing a solution, let’s clarify the problem we’re trying to solve.

Modern AWS environments are rarely simple. You may have:

Multiple VPCs for dev, staging, and production
Separate AWS accounts for security and billing isolation
Shared services like logging, authentication, or monitoring
Hybrid connectivity to on-premises networks

At some point, these networks must talk to each other — securely, reliably, and at scale.

That’s where VPC Peering and Transit Gateway enter the picture.

## What Is Amazon VPC Peering?

VPC Peering is a one-to-one networking connection between two VPCs.

Think of it like a private tunnel directly connecting two houses. There’s no middleman, no detours — just a straight, private path.

Once peered, resources in one VPC can communicate with resources in the other using private IP addresses.

Key Characteristics

One-to-one connection
No bandwidth bottleneck
Low latency
No transitive routing

## How VPC Peering Works Internally

Under the hood, VPC Peering uses AWS’s internal network backbone. Traffic:

Never traverses the public internet
Is encrypted by default
Requires manual route table updates

However — and this is critical — traffic cannot hop.

If VPC A is peered with VPC B, and VPC B is peered with VPC C, A cannot talk to C.

No shortcuts. No exceptions.

## Advantages of VPC Peering

Why do people love VPC Peering? Because it’s simple and fast.

✔ Key Benefits

Very low latency
No additional hourly charges
Simple to configure
Ideal for small architectures
No single point of failure

For two VPCs that just need to communicate — VPC Peering is often the cleanest solution.

## Limitations of VPC Peering

Here’s where the cracks begin to show.

❌ Major Drawbacks

No transitive routing
Complex mesh as VPC count grows
Route table management becomes painful
Hard to scale beyond a few VPCs

Imagine connecting 10 VPCs.

You’d need 45 peering connections.

That’s not architecture — that’s chaos.

## What Is AWS Transit Gateway?

AWS Transit Gateway (TGW) is a hub-and-spoke networking service.

If VPC Peering is a narrow bridge, Transit Gateway is a central airport hub where every route flows through a single control point.

All VPCs, VPNs, and Direct Connect links attach to the Transit Gateway.

## How Transit Gateway Works

Transit Gateway acts as:

A central routing hub
A policy enforcement point
A scalable backbone for your AWS network

Once attached:

VPCs communicate transitively
Routing is centralized
Growth becomes predictable, not painful

## Advantages of Transit Gateway

This is where TGW really flexes 💪

✔ Key Benefits

Transitive routing enabled
Hub-and-spoke architecture
Centralized route management
Scales to thousands of VPCs
Ideal for multi-account setups
Supports VPN and Direct Connect

For large or growing environments, Transit Gateway isn’t just helpful — it’s essential.

## Limitations of Transit Gateway

Transit Gateway is powerful, but not free — in cost or complexity.

❌ Things to Consider

Hourly attachment cost
Data processing charges
Slightly higher latency than peering
Overkill for very small setups

In short: don’t bring a cargo ship to cross a swimming pool.

## Cost Comparison: What Really Costs More?

Here’s the truth: cost depends on scale.

VPC Peering Costs

No hourly cost
Standard data transfer charges

Transit Gateway Costs

Per-hour attachment fee
Per-GB data processing fee

👉 For small environments , peering is cheaper.

👉 For large, complex environments , Transit Gateway often saves money by reducing operational overhead and human error.

## When to Choose VPC Peering

Choose VPC Peering when:

You have 2–3 VPCs
No need for transitive routing
Simple, stable architecture
Low operational overhead required
Cost sensitivity is high

Example:

Frontend VPC ↔ Backend VPC

## When to Choose Transit Gateway

Choose Transit Gateway when:

You have many VPCs
Multiple AWS accounts
Hybrid (on-prem + AWS) networking
Shared services architecture
Rapid growth expected

Example:

Shared services VPC + Dev + QA + Prod + On-Prem

## Real-World Architecture Scenarios

Scenario 1: Startup SaaS (Early Stage)

2 VPCs
One AWS account 👉 VPC Peering

Scenario 2: Growing SaaS Platform

10+ VPCs
Multiple teams 👉 Transit Gateway

Scenario 3: Enterprise with On-Prem

VPN + Direct Connect 👉 Transit Gateway (no debate)

## Common Mistakes and Anti-Patterns

Using VPC Peering for 10+ VPCs
Avoiding TGW due to “cost fear”
Mixing architectures without a plan
Forgetting route table complexity

Remember: operational pain is also a cost.

## Final Decision Framework

Ask yourself:

How many VPCs do I have now?
How many will I have in 6–12 months?
Do I need transitive routing?
Is centralized control important?
Am I optimizing for simplicity or scale?

Your answers will almost always point clearly to one solution.

## Conclusion

Choosing between VPC Peering and Transit Gateway isn’t about which is “better.”

It’s about which one fits your architecture’s present and future.

VPC Peering is simple, fast, and cost-effective — for small setups.
Transit Gateway is scalable, centralized, and enterprise-ready — for growing or complex environments.

Design for where you’re going, not just where you are.

## Frequently Asked Questions (FAQ)

1. Can I use both VPC Peering and Transit Gateway together?

Yes. Many architectures use peering for small, isolated connections and TGW for the core network.

2. Is Transit Gateway slower than VPC Peering?

Slightly, but the difference is usually negligible compared to its scalability benefits.

3. Can VPC Peering connect on-prem networks?

No. Only Transit Gateway supports VPN and Direct Connect natively.

4. Is Transit Gateway overkill for startups?

Early-stage startups may not need it, but fast-growing ones often adopt it sooner than expected.

5. Which is easier to manage long-term?

Transit Gateway — centralized routing always wins at scale.

Kubernetes Architecture Explained for DevOps Engineers

Ravi Kyada — Fri, 26 Dec 2025 07:43:00 +0000

A practical guide to Kubernetes internals for DevOps engineers building and operating clusters.

Continue reading on Cloud Native Journal »

Best Practices for Securing an AWS Environment

Ravi Kyada — Sat, 07 Jun 2025 10:52:48 +0000

A Hands-On Guide to Locking Down Your AWS Cloud with Industry-Backed Security Strategies.

In today’s increasingly cloud-dependent world, organizations face mounting challenges related to data breaches, misconfigured resources, and insider threats.

The flexibility and scalability of AWS are undeniable, but they also demand proactive, intentional security strategies.

AWS operates on a shared responsibility model, where AWS manages the security of the cloud, and you are responsible for security in the cloud. This includes configuring services securely, managing user access, and monitoring for threats.

This guide will walk you through AWS actionable best practices — backed by AWS whitepapers, industry security frameworks like CIS and NIST, and real-world DevSecOps principles — to keep your cloud safe.

Let’s dive deep into best practices to protect your AWS assets — because it’s not just about preventing attacks; it’s about sleeping peacefully at night knowing your cloud is secure.

1. Start with Strong Account Foundations

Security begins at the root — literally. Your AWS root user is the god of your cloud kingdom. Protect it like a vault.

Use Group Email Alias

What happens if the only person who receives AWS alerts is out sick or leaves the company? Disaster.

Use a group email alias (like aws-admin@yourcompany.com) so multiple trusted members stay in the loop for critical updates.

Enable Multi-Factor Authentication (MFA)

Would you secure your bank account with just a password? Nope. AWS is no different.

Enable MFA, especially on the root user and privileged IAM users. It ensures even if a password is compromised, the bad actor still hits a wall.

2. Embrace Identity and Access Management (IAM)

IAM is like the bouncer at your club — only the right people should get access.

Create IAM Users, Not Use Root

Never use the root user for daily tasks. Instead:

Create individual IAM users.
Use roles for cross-account access.
Disable root access keys entirely.

Assign Policies to Groups, Not Users

It’s easier to manage policies when they’re attached to groups. Why?

It reduces configuration errors.
Simplifies access changes.
Keeps your architecture scalable.

3. Rotate and Manage Credentials Carefully

Hardcoding credentials is like hiding your front-door key under the mat — anyone can find it.

Never embed secrets in code.
Use AWS Secrets Manager or Parameter Store.
Rotate keys regularly (especially those older than 90 days).
Delete unused access keys.

4. Audit and Monitor Using Native AWS Tools

Visibility is power. And AWS gives you several spotlights.

Enable CloudTrail Across Regions

CloudTrail records every API call. It’s your surveillance camera.

Enable cloudtrail in all regions , even unused ones, to detect unauthorized activities.

Use CloudWatch, GuardDuty, and Security Hub

CloudWatch : Real-time monitoring and alarms.
GuardDuty : AI-driven threat detection.
Security Hub : Aggregates findings and applies CIS benchmarks.

These tools are your cloud’s security command center.

5. Categorize and Control Your AWS Assets

You wouldn’t guard a garden hose the same way you guard a diamond, right?

Tag resources to:

Identify critical assets.
Apply policies based on risk level.
Automate workflows.

Segregate environments (dev, test, prod) into different accounts for tighter control.

6. Encrypt and Store Secrets Safely

Encryption isn’t just a buzzword — it’s your last line of defense.

Use AWS Key Management Service (KMS).
Control who can decrypt data.
Never store plaintext secrets in config files.

Even if attackers breach your system, encrypted data is just gibberish without the keys.

7. Network Hardening and DNS Protection

Your network is your digital fortress. Fortify it.

Use Amazon VPC Security Best Practices

Create isolated VPCs.
Use NACLs and Security Groups.
Enable VPC Flow Logs to detect suspicious traffic.

Secure DNS Using Route 53 and SSL/TLS

DNS is the phonebook of the internet. If attackers hijack it, they reroute your customers.

Use Amazon Route 53 with DNSSEC.
Encrypt DNS traffic using TLS.
Monitor DNS logs for anomalies.

8. Respond Swiftly to Threats and Abuse

Ever received an AWS abuse warning? You’re not alone.

Have an incident response plan ready. Start by:

Categorizing assets by region.
Using automation to quarantine resources.
Investigating with CloudTrail logs.

A fast response can be the difference between a minor hiccup and a full-blown breach.

9. Backup Strategy: Your Data Safety Net

No backup? Say goodbye to your data during disasters.

Use AWS Backup to automate snapshots.
Store copies across regions.
Test restores periodically — because backups are useless if they don’t work.

10. Automate with Config, Tags, and Scripts

Manual work is a security liability.

Turn on AWS Config to track configuration drifts.
Use tags to group resources for automation.
Explore scripts from AWS Labs for compliance checks.

Automation reduces human error, and that’s where most breaches begin.

11. Mitigate DDoS with Defense-in-Depth

A DDoS attack can turn your application into a paperweight.

Use AWS WAF to filter malicious traffic.
Place workloads behind CloudFront (CDN).
Enable Shield Standard or Shield Advanced for enterprise-grade protection.

12. Clean House: Remove Unused Security Groups

Unused security groups are ghosts that might come back to haunt you.

Audit regularly.
Remove unattached groups.
Document changes for traceability.

13. Establish Robust Naming Conventions

Naming conventions are your AWS GPS. Without them, you’re flying blind.

Example:

Use env-role-service-region (like prod-db-rds-us-east-1).

Don’t use obvious names like admin or fullaccess. Hackers love that.

Conclusion: Build Security into Your Cloud DNA

Security isn’t a feature — it’s a mindset. It must be baked into every step of your AWS journey, not bolted on at the end.

From your root account to your last Lambda function, every resource needs scrutiny, strategy, and a sprinkling of automation.

And remember: it’s not about being perfect. It’s about being resilient, responsive, and always one step ahead.

FAQs

1. What’s the first thing I should do after creating an AWS account?

Enable multi-factor authentication (MFA) on the root user, create IAM users, and disable root access keys.

2. How often should I rotate access keys in AWS?

At least every 90 days, or sooner if required by your security policy.

3. Can I use AWS Secrets Manager for non-AWS applications?

Yes, Secrets Manager can store and retrieve secrets for third-party services like databases and APIs.

4. What’s the difference between NACL and Security Groups?

NACLs are stateless and apply at the subnet level. Security Groups are stateful and apply at the instance level.

5. Do I need to enable CloudTrail in every region?

Yes, to ensure you track activity even in regions you don’t actively use.

Thank you so much for reading the article till the end! 🙌🏻 Your time and interest truly mean a lot. 😁📃

If you have any questions or thoughts about this blog, feel free to connect with me:

🔗 LinkedIn: Ravi Kyada

🐦 Twitter: @ravijkyada

Until next time, ✌🏻 Cheers to more learning and discovery! 🇮🇳 🚀

Mastering Apache Web Server: Installation, Multi-Port Configuration, and Best Practices

Ravi Kyada — Fri, 09 May 2025 10:00:31 +0000

Mastering Apache Web Server for Ubuntu

The Apache HTTP Server is one of the world's most widely used web servers. What keeps Apache popular today is its mature ecosystem and tooling.

Its Features, such as easy integration with Certbot for SSL certificates, .htaccess-based URL rewriting, and seamless 301 redirects, make it incredibly convenient.

While many modern frameworks ship with their own built-in HTTP servers, there’s still value in having a single entry point—a centralized web server or load balancer with one SSL certificate that routes traffic to various services, not just static content.

But have you ever thought beyond the basic setup? What if you need to run Apache on multiple ports or fine-tune it for custom firewall rules? This guide will walk you through everything — from installation to advanced configuration — in a conversational, step-by-step format.

🧱 Introduction to Apache Web Server

Think of Apache as a highly efficient request handler in your web infrastructure. It listens for incoming HTTP requests, processes them based on configured rules and virtual hosts, retrieves the appropriate resources, such as HTML files or dynamic content via PHP, and delivers the response back to the client’s browser.

Acting as a robust intermediary between the server and the internet, Apache ensures that web traffic is routed, managed, and served reliably and securely.

🌐 Why Apache Still Dominates Web Hosting

Despite newer servers like NGINX, Apache’s modular architecture, ease of configuration, and wide support make it a staple in Linux-based web hosting. It’s flexible enough for a simple blog and powerful enough for a multi-site enterprise application.

⚙️ Installing Apache on Ubuntu

To install Apache on Ubuntu-based systems, run:

sudo apt-get install apache2 -y

This command downloads and installs the latest Apache package with all required dependencies.

🗂️ Default Apache File Structure Explained

Post-installation, here are the key paths you should know:

Web root : /var/www/html/index.html
Logs : /var/log/apache2/access.log
Configuration directory : /etc/apache2

📂 Understanding the Apache Directory Hierarchy

Within /etc/apache2, you’ll find:

/sites-available: Where all virtual host configurations live.
/sites-enabled: Active configurations linked from sites-available.

To activate a configuration:

sudo a2ensite your-site.conf

✏️ Editing the Index File

Edit your default landing page:

sudo nano /var/www/html/index.html

Replace the default text with something custom, like:

<h1>Welcome to My Apache Server</h1>

📜 Accessing Apache Logs

For troubleshooting and performance monitoring, logs are your best friend:

sudo tail -f /var/log/apache2/access.log

🔧 Introduction to Apache Configuration Files

Every virtual host must be defined in a config file, usually stored in /etc/apache2/sites-available/. Here's a basic example:

<VirtualHost *:80>
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
</VirtualHost>

🔗 Enabling Apache Sites with a2ensite

Apache provides a helper command to activate virtual hosts:

sudo a2ensite your-site.conf

This symlinks it to /sites-enabled.

🔁 Reloading Apache Gracefully

After making config changes:

sudo systemctl reload apache2

This reloads Apache without dropping current connections.

🧪 Testing Apache Configuration Safely

Before restarting or reloading, test your config:

sudo apachectl configtest

Look for Syntax OK — it’s your green light.

🔀 Configuring Apache to Run on Multiple Ports

Let’s say you want Apache to respond on ports 80 and 81. Start by editing:

sudo nano /etc/apache2/ports.conf

Add:

Listen 81

🏗️ Setting Up Virtual Hosts on Different Ports

Edit your virtual host file:

sudo nano /etc/apache2/sites-available/your-site.conf

Add:

<VirtualHost *:81>
    ServerAdmin admin@example.com
    DocumentRoot /var/www/html
</VirtualHost>

Then enable and reload:

sudo a2ensite your-site.conf
sudo systemctl restart apache2

🔐 Updating Firewall Rules for Apache Access

If using ufw, run:

sudo ufw allow 81

This opens port 81 to the world. Be cautious and restrict access if needed.

☁️ Running Apache on AWS EC2 — Special Considerations

For EC2 instances, you must also:

Add inbound rule in the EC2 security group.
Allow custom TCP on port 81 with source 0.0.0.0/0.

Access it via:

http://<your-ec2-public-ip>:81

🏁 Conclusion

Apache remains an industry standard because of its deep configurability and reliability. From simple setups to multi-port configurations, mastering Apache gives you full control over your server environment.

❓ FAQ

1. Can I run multiple Apache instances on different ports? Yes, but it’s more efficient to configure virtual hosts on different ports within the same Apache instance.

2. What’s the difference between sites-available and sites-enabled? sites-available contains all configurations; sites-enabled contains symlinks to the active ones.

3. Do I need to open firewall ports for each new Apache port? Yes. For every new port, make sure both your system firewall and cloud security group allow traffic.

4. How do I test if Apache is listening on a port? Run: sudo netstat -tuln | grep :81 or ss -tuln

5. What happens if I don’t reload Apache after config changes? Apache won’t pick up the changes, and your new config won’t be active until you reload or restart it.

Ready to level up your web hosting game? Start by experimenting with multi-port configurations and custom virtual hosts today!

Enhance EKS Load Balancing: Enable IPVS Mode in AWS EKS

Ravi Kyada — Mon, 07 Apr 2025 07:45:23 +0000

If you’re running Kubernetes in production, you already know that performance bottlenecks are the stuff of nightmares.

One of the most underrated, impactful changes you can make is switching your cluster’s networking from IPTables to IPVS (IP Virtual Server) mode.

But here’s the challenge: AWS EKS doesn’t support IPVS out of the box. So what do we do? We roll up our sleeves and take the alternative route. in this article, I’ll walk you through exactly how to do it.

TL;DR

If your k8s cluster is handling more than 500–1000Service objects, it’s highly recommended to switch kube-proxy from IpTables to IPVS mode.
In fact, IPVS should almost always be your default choice over iptables mode — it’s faster, more efficient, and built to scale better with large service counts.

And when I say “almost always,” I mean it! If you have a compelling reason to stick with iptables instead of IPVS, drop a comment below — I’d genuinely love to learn from your experience and issues you faces.

🚀 The Need for Speed: Why IPVS Over IPTables?

IPTables handles every packet one by one, scanning a long list of rules like a librarian looking for the right page in an old book.

IPVS, on the other hand, is like a high-speed toll plaza with dedicated lanes and an automated system — it’s built for scale and speed.

In tech terms:

IPTable is rule-based, and slow with scale.
IPVS is connection-based, highly performant, and supports better load-balancing algorithms.

🧱 The AWS EKS Catch: Why You Can’t Enable IPVS Natively

AWS EKS manages the underlying infrastructure, including the base AMI used for your worker nodes. That means you can’t directly enable IPVS modules via the default Amazon EKS-optimized AMI.

To get around this limitation, we’ll have to:

Create a custom EC2 launch template or change user data, we will use user data.
Enable IPVS modules using cloud-init.
Tweak the kube-proxy deployment and config.

Let’s go step by step.

🛠️ Our Workaround High-Level Steps

Create a launch template that installs IPVS on boot.
Deploy nodes using this custom template.
Edit the kube-proxy DaemonSet to use IPVS.
Modify the kube-proxy ConfigMap.
Verify and validate IPVS is running.

🔧 Step 1: Create a Launch Template With IPVS Support

📦 Modifying the EC2 Cloud-Init User Data

The magic starts with the user-data script in your launch template. Paste the following Bash snippet:

#!/bin/bash
sudo yum install -y ipvsadm
sudo ipvsadm -l
sudo modprobe ip_vs
sudo modprobe ip_vs_rr
sudo modprobe ip_vs_wrr
sudo modprobe ip_vs_sh
sudo modprobe nf_conntrack_ipv4

🧩 Why These Kernel Modules Matter

Each modprobe line loads a kernel module essential for IPVS operations:

ip_vs - The core IPVS module.
ip_vs_rr, ip_vs_wrr, ip_vs_sh - Different load-balancing strategies.
nf_conntrack_ipv4 - Enables connection tracking.

Without these, IPVS is like a car with no engine.

🚀 Step 2: Deploy Nodes Using the Custom Launch Template

Attach your launch template to your EKS node group:

Go to the EKS Console or use eksctl.
Use your custom AMI or the default AMI + user-data.

Make sure the nodes spin up successfully and the modules are loaded (you can SSH in and verify with lsmod | grep ip_vs).

🧠 Step 3: Edit the kube-proxy DaemonSet

By default, kube-proxy runs in iptables mode. Time to change that.

Run:

kubectl -n kube-system edit ds kube-proxy

Change:

containers:
- command:
  - kube-proxy
  - --v=2
  - --config=/var/lib/kube-proxy-config/config

To:

containers:
- command:
  - kube-proxy
  - --v=2
  - --proxy-mode=ipvs
  - --ipvs-scheduler=rr
  - --config=/var/lib/kube-proxy-config/config

🌍 Adding IPVS Environment Variable

Add the environment variable too under changes in the daemon set:

env:
- name: KUBE_PROXY_MODE
  value: ipvs

Combined changes we did in daemonSet(For your Better Understanding):

     containers:
     - command:
       - kube-proxy
       - --v=2
       - --proxy-mode=ipvs
       - --ipvs-scheduler=rr
       - --config=/var/lib/kube-proxy/config
       env:
       - name: KUBE_PROXY_MODE
         value: ipvs

🧾 Step 4: Tweak the Kube-Proxy ConfigMap

This step is crucial. Let’s make the IPVS mode permanent in the config. be careful while you make changes here.

Run:

kubectl -n kube-system edit cm kube-proxy-config

🔑 The Key Sections to Modify

Change the following in the config: block:

ipvs:
  scheduler: "rr"
mode: "ipvs"

Complete example:

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  scheduler: "rr"

🔄 Load Balancing Algorithms You Can Use

Choose your poison:

rr: Round Robin
lc: Least Connection
dh: Destination Hashing
sh: Source Hashing
sed: Shortest Expected Delay
nq: Never Queue

After this change restart the daemon set of kube-proxy.

kubectl rollout restart -n kube-system daemonset kube-proxy

⚠️ Common Pitfalls to Avoid

Don’t forget to restart the kube-proxy pods after editing the config.
Your custom AMI must be kept up-to-date with security patches.
Ensure IPVS modules load successfully on each reboot.
Watch out for conflicts between kube-proxy and CNI plugins.

🧪 How to Verify IPVS Is Working as Expected

🔍 Using ipvsadm to Inspect Rules

SSH into one of your worker nodes and run:

sudo ipvsadm -Ln

You should see a list of services and destinations. If you see IPVS table empty, something's wrong—check your kube-proxy config again.

⚖️ Pros and Cons: Should You Go This Route?

Pros:

High-performance packet routing
Better load-balancing strategies
Scales better under pressure

Cons:

More complex to set it up in a better way
Needs custom launch templates
Maintenance overhead

🔮 Future-Proofing: Will AWS Support Native IPVS?

Maybe one day. Currently, AWS does not support a native way to enable IPVS on EKS nodes. But if enough people start requesting it (hint: open a feature request), who knows?

✅ Conclusion: Is the Work-Around Helpful?

So, should you bother?

If you’re running high-throughput, latency-sensitive workloads , then yes, switching to IPVS can make a night-and-day difference. It’s not just a tweak — it’s a performance strategy.

It takes some work, sure. But so does anything worth doing in tech.

❓ FAQ: Your Burning Questions Answered

1. Can I enable IPVS mode without custom launch templates?

No, not currently. AWS’s default AMIs do not come with IPVS kernel modules.

2. Will enabling IPVS affect my existing workloads?

No, as long as kube-proxy is configured correctly, the switch is seamless to your workloads.

3. Is this setup compatible with all CNI plugins?

Most major CNIs like Calico and Cilium support IPVS, but check the documentation for version-specific notes.

4. Can I automate this setup?

Yes! You can bake the user-data script into a Terraform or CloudFormation setup.

5. What’s the performance gain from switching to IPVS?

While mileage may vary, IPVS can handle millions of connections per second , significantly outperforming IPTables in high-load scenarios.

Thank you so much for reading the article till the end! 🙌🏻 Your time and interest truly mean a lot. 😁📃

If you have any questions or thoughts about this blog, feel free to connect with me:

🔗 LinkedIn: Ravi Kyada

🐦 Twitter: @ravijkyada

Until next time, ✌🏻 Cheers to more learning and discovery! 🇮🇳 🚀

5 DevOps Security Best Practices for Your SaaS App

Ravi Kyada — Fri, 04 Apr 2025 04:42:38 +0000

In a world where software applications are increasingly deployed in the cloud, ensuring their security has never been more critical.

Adopting robust security practices is essential for software-as-a-service (SaaS) applications to protect sensitive data and maintain user trust.

DevOps security practices are at the forefront of this transition, enabling teams to build security into their workflows rather than bolting it on as an afterthought.

In this article, we will explore the top five DevOps security best practices tailor-made for your SaaS applications.

1. Implement Secure Coding Practices

Security starts at the code level. By adopting secure coding practices, you reduce the chances of introducing vulnerabilities into your SaaS application right from the development stage.

This means training your development team to write code with security in mind and leveraging secure patterns and frameworks across all stages of the SDLC.

✅ Guidelines:

Follow language-specific secure coding standards (e.g., OWASP ASVS).
Avoid hardcoded secrets; use secrets managers like AWS Secrets Manager or HashiCorp Vault.
Educate developers on secure design and code review practices.

🛡️ Train your development team regularly on secure coding practices to cultivate a security-first culture.

2. Perform Regular Security Testing

Security testing should be continuous — not just a one-time task before production. By integrating both manual and automated testing into your pipeline, you can catch vulnerabilities early and reduce risk.

Static and dynamic analysis : Use SAST and DAST tools to identify insecure code patterns and runtime vulnerabilities.

Manual penetration testing : Engage security professionals or use in-house red team exercises to identify complex issues that automated scanners may miss.

✅ Recommended Actions:

Conduct penetration testing and threat modeling.
Perform regular SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing).
Simulate attacks using tools like OWASP ZAP or Burp Suite.

🎯 Make security testing part of your development sprints and CI/CD process to catch vulnerabilities early.

3. Enforce Least Privilege

The principle of least privilege (PoLP) is crucial in minimizing the attack surface of your application and infrastructure. Every user, service, and system component should only have the permissions necessary to perform their function — and nothing more.

Role-based access control (RBAC): Use RBAC mechanisms across your cloud, Kubernetes, and SaaS systems to tightly control access.

Audit permissions regularly : Avoid privilege creep by reviewing and revoking unused or excessive access rights.

✅ How:

Implement Role-Based Access Control (RBAC) for users and services.
Use Just-In-Time (JIT) access policies where possible.
Audit roles and privileges regularly and revoke unused ones.

🔐 Adhering to PoLP limits the potential impact of compromised credentials or internal threats.

4. Secure CI/CD Pipeline

Your CI/CD pipeline is one of the most sensitive components in your DevOps lifecycle. If compromised, it can lead to supply chain attacks and full control over your deployed environment.

Secure credentials and secrets : Always encrypt secrets and store them in secure vaults instead of in environment files or config scripts.

Isolate build environments : Use containerized or ephemeral environments to prevent attackers from jumping across builds or stages.

✅ Tips:

Use signed commits and enforce branch protection rules.
Store credentials securely (e.g., GitHub Secrets, GitLab CI variables).
Scan dependencies and artifacts before deployment.

🚨 Compromised pipelines can lead to supply chain attacks — always treat them as production environments.

5. Monitor and Respond to Threats

Continuous monitoring and quick incident response are vital in a modern SaaS environment. Even with strong prevention, breaches can happen — so you must detect, alert, and respond effectively.

Centralized logging and SIEM : Aggregate logs across services and integrate with tools to identify anomalies and suspicious behavior.

Incident response planning : Develop and test playbooks regularly to ensure your team knows how to react under pressure.

✅ Tools: Prometheus, Grafana, CloudWatch, ELK Stack, Falco

✅ Strategies:

Centralize logs and use SIEM systems.
Set alerts for unusual behavior or policy violations.
Regularly test incident response playbooks.

👁️ You can’t secure what you don’t monitor. A robust observability setup enables fast detection and recovery.

Bonus Points

6. Hardening Servers and Containers:

The first step towards securing your SaaS application is hardening your servers, containers, and instances operating in the cloud.

This means taking proactive steps to secure services such as NGINX, Apache, MySQL, and Node.js. Here are some key practices:

Secure your operating system: Whether you’re using a virtual machine or a Docker image, ensure that your base OS is hardened against security vulnerabilities.

Use trusted Docker images: Always pull Docker images from well-known and trusted sources in your community to minimize exposure to malicious code.

✅ Practices:

Use minimal base images and keep them updated.
Disable unused services and enforce secure configurations.
Pull images only from trusted sources and verify integrity.

7. Application Security with OWASP

Application security plays a crucial role in protecting sensitive data and processes. Implementing the OWASP Top Ten methodology can significantly enhance your application’s security posture. This framework helps your development team understand and mitigate common vulnerabilities such as:

Cross-Site Scripting (XSS)
SQL Injection
Cross-Site Request Forgery (CSRF)
Security misconfigurations

By adhering to OWASP’s guidelines, your development team will be better prepared to identify potential security flaws early in the development cycle.

✅ Focus Areas:

Prevent XSS, SQL Injection, and CSRF.
Sanitize all inputs and apply proper error handling.
Stay updated on OWASP’s evolving list of vulnerabilities.

8. Automated Scanning of Containers

Integrating security checks into your Continuous Integration/Continuous Deployment (CI/CD) pipeline is vital. Using tools like Snyk, SonarQube, or Aqua can help automate the scanning of containers and application code.

Detect vulnerabilities: These tools inspect your containers, operating system, and code for vulnerabilities, allowing you to catch issues before they make it to production.

Ensure compliance: By consistently running these scans, you can ensure that your deployments comply with your organization’s security policies and regulatory requirements.

9. Securing Your Cloud Environment

When utilizing cloud services such as AWS, Google Cloud, or Azure, security configuration must be prioritized. Here are some key points for securing your cloud environment:

Using Virtual Private Cloud (VPC): Create public and private subnets within your VPC to segment resources effectively. Schedule critical services in private subnets while exposing only necessary services through public subnets.

Kubernetes security: Safeguard your Kubernetes clusters through:

Namespace handling: Configure namespaces to isolate resources effectively.

Role-Based Access Control (RBAC): Implement RBAC to restrict access to sensitive systems and data.

10. Implement a Reliable Backup Ecosystem

Backing up your data and systems is critical for disaster recovery, albeit it may not seem directly related to security. By implementing robust backup practices, you ensure that data can be quickly restored in the event of a security incident.

Use managed services like AWS RDS for automatic backups of your databases.
Regularly backup EC2 instances automatically, ensuring rapid recovery in case of incidents.
Consider using infrastructure as code tools like Terraform to automate and version your entire production environment to facilitate quick and effective recovery if needed.

✅ Final Thoughts:

DevOps isn’t just about shipping fast — it’s about shipping securely and confidently. By implementing these 10 practices, your team can build a resilient SaaS app that’s ready to withstand modern security threats without compromising agility.

Implementing these top five DevOps security best practices can significantly enhance your SaaS application’s resilience against potential threats.

Prioritizing security measures such as hardening your servers and containers, adhering to established frameworks like OWASP, and integrating automated scanning tools into your CI/CD processes can create a robust defense mechanism for your applications.

Furthermore, maintaining a reliable backup ecosystem ensures you can quickly recover from potential disasters.

By adopting these best practices, you not only protect your application but also build trust with your users.

If you’re looking for further assistance or specific solutions related to DevOps security practices for your SaaS application, explore Medium Profile.

Thank you so much for reading the article till the end! 🙌🏻 Your time and interest truly mean a lot. 😁📃

If you have any questions or thoughts about this blog, feel free to connect with me:

🔗 LinkedIn: Ravi Kyada

🐦 Twitter: @ravijkyada

Until next time, ✌🏻 Cheers to more learning and discovery! 🇮🇳 🚀

AWS EKS IP Exhaustion: Causes, Solutions, and Best Practices

Ravi Kyada — Tue, 18 Mar 2025 10:31:13 +0000

Imagine your AWS EKS cluster running smoothly in production, all CI/CD pipelines are working without any issues, services are scaling gracefully, and everything feels like autopilot mode. — Until one day, new pods fail to start.

So what’s going on?

You dive into kubectl get pods and there it is — a bunch of pods stuck in Pending state.

The logs say it all:

Failed to assign an IP address: ENI IP address limit reached.

That’s when it hits you — this isn’t about compute power. It’s a network-level bottleneck. You’re out of allocatable IP addresses in your cluster.

At first, everything seems normal. But as your workloads scale, pods suddenly get stuck in a Pending state. The culprit? IP exhaustion.

Networking is the backbone of Kubernetes on AWS, and if not planned correctly, it can lead to serious scaling issues.

This guide explores why IP exhaustion happens in AWS EKS, how to detect it early, and what best practices you should follow to prevent it.

Understanding IP Exhaustion in AWS EKS

AWS EKS assigns an IP address to every pod using the AWS VPC CNI (Container Network Interface). While this provides native networking integration with AWS, it also means:

Every pod consumes an IP from the subnet CIDR block.
AWS reserves five IPs per subnet , reducing the available range.
Small CIDR blocks fill up quickly, leading to eventual IP exhaustion.

The available IP pool shrinks as your cluster scales, preventing new pods from running.

How AWS EKS Assigns IPs

AWS VPC CNI and Its Role

The AWS VPC CNI plugin manages pod-to-IP allocation using the primary VPC CIDR block. Here’s how it works:

Each Kubernetes node gets an Elastic Network Interface (ENI).
The ENI gets multiple secondary IPs , assigned to running pods.
The number of available IPs depends on the node instance type.

For example, an m5.large instance supports 10 pods per ENI, meaning if you run more, you’ll need another ENI — consuming even more IPs.

Why Does IP Exhaustion Happen?

Subnet Size Limitations
AWS reserves five IPs per subnet.
Small subnets (e.g., /25) run out of addresses faster.
Scaling Issues
More pods = more IPs required.
Without proper planning, clusters grow beyond their available IPs.
Incorrect CIDR Block Allocation.
Using a /25 CIDR for a large cluster is insufficient.
A /20 or /21 CIDR is recommended for high-scale deployments.

Signs That Your Cluster Is Running Out of IPs

Pods are stuck in Pending state.
aws-node logs show IP exhaustion errors.
CloudWatch logs indicate subnet IP depletion.

Run the following command to check available IPs:

kubectl get pods -A -o wide | grep Pending

Or monitor subnet usage with AWS CLI:

aws ec2 describe-subnets --filters "Name=vpc-id,Values=<your-vpc-id>" --query 'Subnets[*].[SubnetId,AvailableIpAddressCount]'

Best Practices to Prevent IP Exhaustion

1. Use a Larger CIDR Block

Start with a /20 or /21 instead of /25 or /24.
This provides thousands of IPs for your cluster.
Example setup:

aws ec2 create-vpc --cidr-block 10.0.0.0/20

2. Use Nitro-Based Instances

Nitro instances support Prefix Delegation , reducing IP overhead.
Example: c6g, m6g, and r6g instances allow prefix-based IP allocation.

3. Leverage Secondary CIDR Blocks

Add extra CIDR blocks to your VPC.
This prevents a single subnet from exhausting all available IPs.

aws ec2 associate-vpc-cidr-block --vpc-id <your-vpc-id> --cidr-block 10.1.0.0/16

4. Enable Prefix Delegation

Prefix delegation allows ENIs to allocate smaller subnet prefixes instead of full IPs. This significantly reduces IP waste.

To enable it:

kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true

5. Use AWS PrivateLink for Services

Avoid assigning public IPs where unnecessary.
AWS PrivateLink routes traffic internally , saving IPs.

Monitoring IP Usage in AWS EKS

Use CloudWatch and aws-node logs to track available IPs:

kubectl logs -n kube-system aws-node | grep "IP exhaustion"

Set up alerts with Amazon CloudWatch:

aws cloudwatch put-metric-alarm --alarm-name IP-Exhaustion-Alert \
  --metric-name AvailableIPCount --namespace AWS/VPC \
  --threshold 10 --comparison-operator LessThanThreshold \
  --evaluation-periods 1 --alarm-actions arn:aws:sns:region:account-id:topic-name

Debugging IP Exhaustion Issues

1. Identify Stuck Pods

kubectl get pods --all-namespaces -o wide | grep Pending

2. Check IP Availability

aws ec2 describe-subnets --query 'Subnets[*].[SubnetId,AvailableIpAddressCount]'

3. Restart aws-node DaemonSet

kubectl rollout restart daemonset aws-node -n kube-system

Case Study: Preventing IP Exhaustion in a Growing EKS Deployment

A SaaS startup faced scaling issues as its EKS cluster outgrew a /25 subnet. Pods were failing, and deployments stalled. The solution:

✅ Migrated to a /20 CIDR block for long-term scalability.

✅ Switched to Nitro instances for Prefix Delegation support.

✅ Used AWS PrivateLink to reduce public IP allocation.

Within a few weeks, they eliminated IP exhaustion issues and achieved seamless scaling.

Conclusion

AWS EKS networking must be planned in advance to avoid IP exhaustion issues. Using a proper CIDR block , enabling Prefix Delegation , and monitoring IP consumption will prevent costly scaling failures.

By implementing these best practices, you can ensure your Kubernetes workloads scale smoothly without hitting network roadblocks. 🚀

FAQ

1. What is AWS VPC CNI, and how does it assign IPs?

AWS VPC CNI assigns IPs from the VPC CIDR block to each pod running in EKS. It does this via Elastic Network Interfaces (ENIs) attached to EC2 nodes.

2. How can I check if my AWS EKS cluster is running out of IPs?

Run:

kubectl get pods -A -o wide | grep Pending

Or check available IPs in subnets:

aws ec2 describe-subnets --query 'Subnets[*].[AvailableIpAddressCount]'

3. What’s the best CIDR block size for an EKS cluster?

A /20 or /21 CIDR block is recommended for large-scale deployments to avoid early IP exhaustion.

4. How does Prefix Delegation improve IP efficiency?

Prefix Delegation allows ENIs to allocate IPs more efficiently , reducing waste and increasing scalability.

5. Can I add more IPs to an existing AWS EKS cluster?

Yes! You can associate a secondary CIDR block to your VPC to expand available IPs without downtime.

By implementing these strategies, you’ll future-proof your AWS EKS networking and avoid painful IP exhaustion issues. 🚀

Thank you so much for reading the article till the end! 🙌🏻 Your time and interest truly mean a lot. 😁📃

If you have any questions or thoughts about this blog, feel free to connect with me:

🔗 LinkedIn: Ravi Kyada

🐦 Twitter: @ravijkyada

Until next time, ✌🏻 Cheers to more learning and discovery! 🇮🇳 🚀

How to Automate Tasks in Linux with Cron Jobs and Shell Scripting (Step-by-Step Guide)

Ravi Kyada — Mon, 17 Mar 2025 12:44:30 +0000

Imagine never having to execute a repetitive task again manually. What if your computer could effortlessly handle scheduled maintenance, database backups, or log rotations?

That’s exactly what Automate Tasks in Linux with Cron Jobs and Shell Scripting helps you to do! Whether you’re a seasoned sysadmin or just diving into automation, mastering cron jobs can save you valuable time and effort.

Have you ever wondered how system tasks run at precise intervals without human intervention? That’s the magic of cron jobs! By leveraging Automate Tasks in Linux with Cron Jobs and Shell Scripting , you can set up tasks to execute on a schedule — be it hourly, daily, weekly, or even by the second.

Let’s dive deep into how cron jobs work, how to configure them, and how to enhance your automation with cron.

What is Task Automation in Linux?

Task automation in Linux allows users to execute scripts and commands at predefined times, eliminating the need for manual intervention.

Whether it’s system maintenance, backups, or log management, automation ensures efficiency and reliability.

Why Use Cron Jobs and Shell Scripts?

Cron jobs schedule tasks, while shell scripts define a sequence of commands to execute. Together, they form a powerful automation system for Linux users, developers, and sysadmins.

Understanding Cron Jobs

What is a Cron Job?

A cron job is a scheduled task that runs automatically at specified intervals. The Linux cron daemon (cron.service) manages these jobs, executing them in the background.

How Does the Cron Daemon Work?

The cron daemon reads the crontab file, which contains scheduled tasks. When the system time matches a cron entry, the corresponding command runs automatically.

To check if the cron daemon is active:

sudo systemctl status cron.service

Crontab: The Heart of Cron Jobs

What is Crontab?

Crontab (Cron Table) is a file where users define scheduled tasks.

How to Edit Crontab Entries

Use the following command to edit your crontab:

crontab -e

Crontab Syntax Explained (* * * * *)

Crontab uses a five-field format:

* * * * * command_to_execute
| | | | |
| | | | +---- Day of the week (0 - 7) [Sunday = 0 or 7]
| | | +------ Month (1 - 12)
| | +-------- Day of the month (1 - 31)
| +---------- Hour (0 - 23)
+------------ Minute (0 - 59)

Example: Run a script every day at 5 AM

0 5 * * * /path/to/script.sh

Creating a Simple Cron Job

Example: Scheduling a Script to Run Every Minute

Let’s create a simple script that logs the current date to a file.

1. Create the Script

echo `date` >> /root/date-out.txt

2. Make it Executable

chmod 775 /root/date-script.sh

3. Add it to Crontab

crontab -e

Add the following line:

*/1 * * * * /bin/sh /root/date-script.sh

Redirecting Cron Output

To capture the output of a cron job, use:

* * * * sh /path/to/script.sh &> log_file.log

Redirecting Output to Log Files

To capture cron job output:

* * * * * /path/to/script.sh >> /var/log/cron_output.log 2>&1

Checking Cron Job Execution History

Check system logs:

cat /var/log/syslog | grep CRON

Introduction to Shell Scripting

Shell scripting automates repetitive tasks by executing a series of commands in a script file. Instead of typing commands manually, you can write a script and run it automatically.

Types of Shells

Bourne Shell (sh)
C Shell (csh)
Korn Shell (ksh)
GNU Bourne-Again Shell (bash)

Basic Shell Scripting Example

Create a script file:

#!/bin/sh
echo "Hello, World!"

Make it executable:

chmod +x test.sh
./test.sh

Using Variables in Shell Scripts

name="John"
echo "Hello, $name!"

Reading User Input

read user_name
echo "Hello, $user_name!"

Making Variables Read-Only

readonly VAR_NAME

Unsetting Variables

unset VAR_NAME

Writing Your First Shell Script

Creating a Script File

touch my_script.sh

Adding Execute Permissions

chmod +x my_script.sh

Writing a Simple Script

#!/bin/bash
echo "Hello, World!"

Running the Script

./my_script.sh

Automating Tasks with Shell Scripts and Cron Jobs

Scheduling a Shell Script with Cron

0 3 * * * /path/to/my_script.sh

Runs the script daily at 3 AM.

Using Cron Jobs for Database Management

Automating MySQL Backups

0 2 * * * mysqldump -u root -p mydatabase > /backup/db_backup.sql

Runs a database backup at 2 AM daily.

Common Cron Job Mistakes and Fixes

Path Issues

Use absolute paths:

/bin/bash /home/user/script.sh

Permission Problems

Ensure the script has execute permissions:

chmod +x /home/user/script.sh

Conclusion

Cron jobs and shell scripting make Linux automation seamless and efficient. Mastering these tools saves time and ensures system stability.

FAQ

1. How do I list all my cron jobs?

Run:

crontab -l

2. How do I remove a cron job?

Edit crontab and delete the relevant line:

crontab -e

3. Can I schedule cron jobs as a different user?

Yes, using:

sudo crontab -u username -e

4. How do I ensure my cron job is running?

Check logs:

cat /var/log/syslog | grep CRON

5. Why isn’t my cron job executing?

Ensure:

The script has execute permissions (chmod +x script.sh)
Absolute paths are used
The cron daemon is running (sudo systemctl status cron.service)

This guide covers everything you need to master Linux automation using cron jobs and shell scripting. Start automating today!

Thank you so much for reading the article till the end! 🙌🏻 Your time and interest truly mean a lot. 😁📃

If you have any questions or thoughts about this blog, feel free to connect with me:

🔗 LinkedIn: Ravi Kyada

🐦 Twitter: @ravijkyada

Until next time, ✌🏻 Cheers to more learning and discovery! 🇮🇳 🚀

The Smart Way to Manage Multiple GitHub Accounts in Linux CLI

Ravi Kyada — Wed, 26 Feb 2025 10:35:43 +0000

If you work with multiple GitHub accounts, such as personal and work accounts, you may face challenges when pushing code to different repositories.

Managing multiple GitHub accounts in Linux can be tricky, but with the right setup, it becomes seamless.

Whether you’re juggling a personal and a work account, or contributing to different organizations, this guide will walk you through setting up and switching between multiple GitHub accounts effortlessly using SSH keys.

Challenges & Common Issues

Before diving into the solution, let’s explore the common challenges:

Authentication conflicts : You might be logged in with your personal account but need to push to a work repository.
Wrong identity in commits : If Git uses the wrong email and username, your commits may not be correctly attributed.
Permission errors : Cloning a repo but realizing you lack the correct SSH key permissions.

Luckily, all these issues can be resolved by setting up multiple SSH keys and configuring Git correctly.

Step 1: Generating SSH Keys

For each GitHub account, you need a separate SSH key. Run the following commands:

ssh-keygen -t ed25519 -C "your_personal_email@example.com" -f ~/.ssh/id_ed25519_personal
ssh-keygen -t ed25519 -C "your_work_email@example.com" -f ~/.ssh/id_ed25519_work

This will create:

~/.ssh/id_ed25519_personal (Private key)
~/.ssh/id_ed25519_personal.pub (Public key)
~/.ssh/id_ed25519_work (Private key)
~/.ssh/id_ed25519_work.pub (Public key)

Step 2: Adding SSH Keys to GitHub

Next, copy and add the public keys to GitHub:

cat ~/.ssh/id_ed25519_personal.pub
cat ~/.ssh/id_ed25519_work.pub

Go to GitHub → Settings → SSH and GPG keys and add the corresponding keys to each account.

Step 3: Configuring SSH

Modify your SSH config file:

nano ~/.ssh/config

Add the following:

# Personal GitHub Account
Host github.com-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes

# Work GitHub Account
Host github.com-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

This ensures Git uses the correct SSH key for each account.

Step 4: Testing SSH Connections

Verify that each key is correctly associated:

ssh -T git@github.com-personal
ssh -T git@github.com-work

If successful, you’ll see:

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

Step 5: Cloning Repositories Using Different Accounts

When cloning repositories, use:

Personal account:

git clone git@github.com-personal:your_username/repo.git

Work account:

git clone git@github.com-work:your_work_username/repo.git

Step 6: Configuring Git Identity Per Repository

Set user details inside the repository:

cd repo_name
git config user.name "Your Name"
git config user.email "your_email@example.com"

For global settings:

nano ~/.gitconfig

[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work
[includeIf "gitdir:~/personal/"]
    path = ~/.gitconfig-personal

Step 7: Managing SSH Keys Efficiently

Use SSH-Agent to manage keys:

ssh-add ~/.ssh/id_ed25519_personal
ssh-add ~/.ssh/id_ed25519_work

To list added keys:

ssh-add -l

Alternative Method: HTTPS Credential Helper

Instead of SSH, use HTTPS and personal access tokens:

git config --global credential.helper cache
git clone https://github.com/your_username/repo.git

GitHub will prompt you for credentials, and you can use a personal access token instead of a password.

Automating with Scripts

Create a script to switch accounts:

echo "Switching to Work Account"
ssh-add ~/.ssh/id_ed25519_work

Troubleshooting Common Issues

SSH key not being used? Use ssh -vT git@github.com-personal to debug.
Permission denied? Ensure the SSH key is added to GitHub.

Best Practices

Keep SSH keys secure.
Use meaningful SSH hostnames.
Use HTTPS for occasional access instead of adding too many SSH keys.

Conclusion

Managing multiple GitHub accounts in Linux becomes easy with SSH keys and proper configuration. By following this guide, you can avoid authentication issues and switch between accounts seamlessly.

FAQ

1. Can I use SSH and HTTPS for different accounts?

Yes! You can use SSH for one account and HTTPS for another.

2. How do I remove an SSH key from GitHub?

Go to Settings → SSH and GPG keys , and remove the unwanted key.

3. What if I accidentally commit with the wrong account?

Use:

git commit --amend --author="Correct Name <correct@email.com>"

4. Can I use the same SSH key for multiple GitHub accounts?

No, each GitHub account requires a unique SSH key.

5. How can I see which SSH key Git is using?

Run:

ssh -T git@github.com

By following these steps, you can efficiently manage multiple GitHub accounts on Linux! 🚀

Thank you so much for reading the article till the end! 🙌🏻 Your time and interest truly mean a lot. 😁📃

If you have any questions or thoughts about this blog, feel free to connect with me:

🔗 LinkedIn: Ravi Kyada

🐦 Twitter: @ravijkyada

Until next time, ✌🏻 Cheers to more learning and discovery! 🇮🇳 🚀

Updating WordPress and Managing Secure Permissions for PHP

Ravi Kyada — Thu, 20 Feb 2025 08:41:57 +0000

Imagine you leave your front door unlocked at night. Would you sleep peacefully? Probably not. Yet, many WordPress users unknowingly leave their websites vulnerable by neglecting updates and mismanaging file permissions.

If you’ve ever encountered errors like “The update cannot be installed because some files could not be copied” , chances are your file permissions are not properly set.

But don’t worry! In this guide, you’ll learn not just how to update WordPress safely but also how to set up the correct permissions for maximum security and performance.

Preparing for a WordPress Update

Backing Up Your Site

Before you update, think of it like skydiving — you wouldn’t jump without a parachute, right? The same goes for your website. Always back up your files and database before updating.

Use UpdraftPlus , All-in-One WP Migration , or your web host’s backup feature.
Backup manually using phpMyAdmin for the database and FTP/SFTP for files.

Checking for Compatibility Issues

Ensure all plugins and themes are compatible with the new WordPress version.
Use a staging environment to test updates before applying them to your live site.

How to Update WordPress Safely

Using the WordPress Dashboard

The easiest way to update WordPress is through the admin panel:

Navigate to Dashboard > Updates.
Click Update Now.
Wait for the update to complete.

Updating via FTP or SFTP

If the automatic update fails, you can manually update via FTP:

Download the latest WordPress version from wordpress.org.
Extract the .zip file.
Upload everything except wp-config.php and wp-content to your server.
Run the Database Update prompt (/wp-admin/upgrade.php).

Manual Update via SSH

For developers, an SSH-based update is faster:

cd /var/www/wordpress
wp core update

Understanding File Permissions in WordPress

What Are File Permissions?

File permissions define who can read, write, and execute files on your server.

Breaking Down Permission Numbers

644 → Files (Owner: Read/Write, Group & Others: Read)
755 → Directories (Owner: Full Access, Group & Others: Read/Execute)
775 → Some servers require this for group editing
600 → wp-config.php (for extra security)

The Importance of Secure PHP Permissions

When your PHP files have the wrong permissions, malicious scripts can execute , or updates can fail.

Why File Ownership Matters

The recommended owner for WordPress files is www-data (Apache/Nginx):

chown -R www-data:www-data /var/www/wordpress

Correct WordPress File & Directory Permissions

Set Secure Permissions Using These Commands:

find /var/www/wordpress -type d -exec chmod 755 {} \;
find /var/www/wordpress -type f -exec chmod 644 {} \;
chmod 600 /var/www/wordpress/wp-config.php

Advanced: Adjusting Ownership for Security

If permissions alone don’t fix your issue, update ownership:

chown -R www-data:www-data /var/www/wordpress

Fixing Common Permission Errors

“Cannot Install Plugin or Theme” Error → Check write permissions on /wp-content/uploads/.
“Failed to Write File” Error → Ensure directories are 755 and files 644.

Using FS_METHOD for Direct File Updates

Modify wp-config.php:

define('FS_METHOD', 'direct');

This forces WordPress to update without FTP credentials.

Hardening WordPress Security Beyond Permissions

Restrict access to wp-config.php:

chmod 600 /var/www/wordpress/wp-config.php

Disable file editing in the admin panel:

define('DISALLOW_FILE_EDIT', true);

Automating Permission Fixes with a Script

Create a shell script:

#!/bin/bash
find /var/www/wordpress -type d -exec chmod 755 {} \;
find /var/www/wordpress -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/wordpress

Checking Server Logs for Permission Errors

Use:

tail -f /var/log/apache2/error.log

When to Contact Your Web Host

If none of these fixes work, your host may restrict file access. Contact support.

Final Thoughts on Security & Updates

Keeping WordPress updated and securing permissions is like locking your doors. You want to strike a balance between security and functionality.

FAQs

1. Why do my WordPress updates fail?

Usually due to incorrect file permissions or ownership issues.

2. Should I use 777 permissions?

Never! This makes your site vulnerable to attacks.

3. How do I know if my permissions are correct?

Use:

ls -la /var/www/wordpress

4. What if my host doesn’t allow permission changes?

Some managed hosting providers have locked file permissions. Contact them.

5. Does incorrect ownership affect performance?

Yes. It can cause slow updates, plugin failures, and security risks.

Thank you so much for reading the article till the end! 🙌🏻 Your time and interest truly mean a lot. 😁📃

If you have any questions or thoughts about this blog, feel free to connect with me:

🔗 LinkedIn: Ravi Kyada

🐦 Twitter: @ravijkyada

Until next time, ✌🏻 Cheers to more learning and discovery! 🇮🇳 🚀

Resolving SSH Authentication Issues in Jenkins: A Step-by-Step Guide

Ravi Kyada — Mon, 17 Feb 2025 06:36:57 +0000

Jenkins is a widely used automation tool, that helps developers streamline CI/CD workflows.

One common use case is deploying applications or running commands on remote servers via SSH using the Publish Over SSH plugin.

However, many users face authentication errors that prevent successful connections.

One such error is:

ardjenkins.plugins.publish_over.BapPublisherException: Failed to connect and initialize SSH connection. Message: [Failed to connect session for config [.....]. Message [Auth fail]]

This blog will help you understand why this happens and how to resolve it with a simple SSH configuration update.

Understanding the Issue

Why Does the SSH Authentication Error Occur?

This issue occurs due to recent security changes in OpenSSH , where ssh-rsa has been deprecated as a default authentication method. If your remote server runs a newer version of OpenSSH (such as on Ubuntu 20.04 or 22.04 ), it may reject authentication attempts using older RSA keys.

This is why Jenkins’ Publish Over SSH plugin may fail to connect, even if your SSH key is correctly stored in Jenkins credentials.

How to Identify the Issue?

If you try to connect manually using SSH, you may see this error in the remote machine’s logs (/var/log/auth.log):

userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
error: Received disconnect from XX.XX.XX.XX port 54588:3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Disconnected from authenticating user ubuntu XX.XX.XX.XX port 54588 [preauth]

This log confirms that ssh-rsa is not an accepted key type on the remote server.

The Solution: Updating SSH Configuration

To resolve this, you need to allow ssh-rsa keys on the remote server explicitly.

📌 Step-by-Step Fix

Follow these steps on the remote machine:

1️⃣ Access the Remote Machine

ssh user@remote-server

2️⃣ Edit the SSH Configuration File

Use a text editor like vi or nano to modify the SSH daemon configuration:

sudo vi /etc/ssh/sshd_config

3️⃣ Enable Public Key Authentication

Look for the following line and uncomment it (remove the # if present):

PubKeyAuthentication yes

Then, add this line at the bottom of the file :

PubKeyAcceptedKeyTypes=+ssh-rsa

This tells OpenSSH to accept SSH-RSA keys , restoring compatibility with Jenkins’ Publish Over SSH plugin.

4️⃣ Save and Exit the File

If using vi, press ESC, type :wq, and hit Enter.
If using nano, press CTRL + X, then Y, and Enter to save changes.

5️⃣ Restart SSH Service

After making the changes, restart SSH for them to take effect:

udo systemctl restart sshd

6️⃣ (Optional) Reboot the Machine

If the fix does not take effect immediately, try rebooting:

sudo reboot

Verifying the Fix

Once your remote server has restarted the SSH service (or rebooted), go back to Jenkins and try running your Publish Over SSH job again.

It should now successfully connect to the remote server without the authentication error. 🎉

Why Did This Fix Work?

By default, OpenSSH in newer Linux distributions disables ssh-rsa for security reasons. The fix works because:

✅ PubKeyAuthentication yes → Ensures SSH key authentication is enabled.

✅ PubKeyAcceptedKeyTypes=+ssh-rsa → Allows ssh-rsa keys that were previously blocked.

These changes restore compatibility between Jenkins and your remote machine, allowing SSH connections to succeed.

Additional Troubleshooting

If you’re still facing issues, try these steps:

1️⃣ Ensure Jenkins Uses the Correct SSH Key

If Jenkins still fails to connect, check if the correct SSH private key is configured in Jenkins credentials.

Go to Manage Jenkins → Manage Credentials
Find the SSH key stored for your server
Ensure it matches the public key on the remote server (in ~/.ssh/authorized_keys).

You can also manually test if your key works:

ssh -i /path/to/your/key user@remote-server

2️⃣ Test SSH Connectivity from the Jenkins Machine

Try connecting manually from the Jenkins server to see if the SSH authentication succeeds:

ssh user@remote-server -v

If you see “Auth fail” , it means the server is still rejecting your key.

3️⃣ Try Regenerating SSH Keys

If your SSH key is old, try generating a new RSA key pair on your Jenkins machine:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa

Then, add the new public key (id_rsa.pub) to the remote server’s ~/.ssh/authorized_keys file.

Alternative Approach: Upgrade Your Key Type

Instead of re-enabling ssh-rsa, consider upgrading to a more secure key type like ED25519 or ECDSA.

To generate a new ED25519 key :

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

Then, add the new public key to the remote machine:

cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys

Update Jenkins to use this new key in Manage Credentials.

This method is more secure and recommended for modern OpenSSH setups.

Conclusion

If you are facing SSH authentication errors in Jenkins’ Publish Over SSH plugin, the root cause is often new OpenSSH security policies that disable ssh-rsa.

The best solution is to modify the SSH daemon config on the remote machine to explicitly allow ssh-rsa keys:

Uncomment PubKeyAuthentication yes
Add PubKeyAcceptedKeyTypes=+ssh-rsa
Restart the SSH service

If possible, consider upgrading to stronger key types like ED25519 for improved security.

By following these steps, you can successfully restore Jenkins SSH connectivity , ensuring your automation pipelines run smoothly! 🚀

💬 Have You Faced This Issue?

Have you encountered SSH authentication failures with Jenkins? What worked for you? Let us know in the comments! 👇

🔗 For more details, refer to the original GitHub issue .