Thank you for reading The Cloud Handbook. As a token of our appreciation, we’re offering you a limited-time offer of 40% off a paid subscription for life.

Redeem special offer

Here are the benefits you unlock with a paid subscription:

• Weekly deep dives on cloud engineering & technologies

• Access to all cloud projects, labs, guides, and AWS certification resources.

• For Yearly Subscribers, 1:1 Guidance through chat (career, technical). Access to our community chat with 100+ members.

Join the many readers who pay for full access to The Cloud Handbook - redeem your special offer today!

Thanks again for reading.

Recent Posts

In this article, we discuss how DevOps can serve as an accelerator to quicker product development and why CI/CD pipelines play a big role, and the cultural transformation is needed.

Let’s get started.

Why Businesses Must Keep Innovating

Over time we have seen that speed of innovation has been identified as a key business-differentiating factor. The balance in the market has changed hugely over the past years. The old paradigm of producing software every six months or every year does not apply to most industries in todays software market.

This high rate of speed required cannot be achieved at the cost of quality and stability. Users want an updated application but also they require reliable secure and performant applications. This is where DevOps comes in handy, it gives the system in accomplishing the speed and quality both.

Understanding DevOps

So, What exactly is DevOps?

DevOps is not a role, or any specific tools. It’s a cultural movement.

DevOps as a cultural and technical adjustment was a reaction to avoiding friction between development and operations teams. In past, teams had different priorities, interests, tools, and even metrics of success. Developers had to push the features out into the market fast, but the operations team was keener on stableness and the uptimes.

This division brought about the inherent conflict within the software development lifecycle. What would be handed over the wall is that code into the operations world and oftentimes ended up in some sort of deployment problems, and type of finger-pointing or in a delay of the release. The feed-back mechanism was long and ineffective.

DevOps is a system that prevents such barriers to coordination and collaborates between departments. It leads to cooperation, communication and integration between software developers and IT operations.

The main DevOps principles are continuous integration, continuous delivery, infrastructure as code, monitoring, and logging and a collaborative culture.

Later in this article we will discuss this in detail.

DevOps Culture

DevOps is more about Cultural shift than some specific tools as we mentioned already. DevOps clearly has a cultural dimension besides the technological one ensured by the use of CI/CD pipelines: it is all about changing the way people think.

The Problem with Traditional Silos

In conventional IT organizations the development teams are traditionally evaluated on the basis of velocity of delivering features and the volume of new capabilities that they can develop. Operations teams are instead graded in system uptime, stability, and performance. The conflicting incentives that are created by these various success metrics make innovation lag.

Speed is a primary concern of the developers and stability is considered a priority of the operations teams, so it is clear that conflict will occur. Developers might want to roll out rapid feature releases, and operations might want to avoid any modifications to the system which can cause an alteration to the stability of the system. The tension produces long change approval mechanisms, large volumes of manual testing and conservative release cycles.

The DevOps Cultural Transformation

DevOps culture facilitates shared accountability of application performance throughout software development lifecycle.

Under a DevOps culture, operation issues such as monitoring, optimization of performance, and incident response become areas in which the developers participate. Operations engineers, in particular, find themselves engaged in the development process and give their input in matters of architecture and attempt to develop systems that are innovative but sound in operations.

Cross-Functional Teams and T-Shaped Skills

The DevOps culture means a restructuring of teams so that those teams become more cross-functional with team members with a wider skill set, able to cover across multiple spheres. The T-shaped model of skills that allow employees to have in-depth knowledge on one aspect and huge breadth of knowledge in various others makes it possible to achieve independence among teams and speed up the processes.

With a thorough knowledge of development and operations issues, team members are able to make more informed decisions when it comes to making trade-offs between features, performance and reliability. They are also able to work more effectively since they do not need to wait until specialists in other departments can resolve matters within their focus of expertise.

Measurable Impact on Time-to-Market

The benefits of DevOps for innovation aren’t just theoretical—they can be measured and quantified. Organizations that have successfully implemented DevOps practices consistently report significant improvements in their ability to bring products to market quickly.

Key Performance Indicators

Several key metrics demonstrate the impact of DevOps on innovation speed:

1. Deployment Frequency: This measures how often an organization deploys code to production. Higher deployment frequency enables faster delivery of new features and faster response to customer needs.

2. Lead Time for Changes: This measures the time from when code is committed to when it’s running in production.

3. Mean Time to Recovery (MTTR): When issues occur in production, this measures how quickly they can be resolved. Faster recovery times enable teams to take more risks and experiment more boldly, knowing that issues can be resolved quickly.

4. Change Failure Rate: This measures the percentage of deployments that cause production incidents. Lower failure rates enable more frequent deployments and faster innovation cycles.

The DevOps Lifecycle

DevOps lifecycle most often consists of five stages: Plan, Build, Test, Release and Monitor. Every phase incorporates certain activities and techniques that boost the whole innovation process.

1. Plan: Aligning Development with Business Goals

The planning stage is all about requirement, feature prioritization and development roadmap. Plan is shared and such planning occurs in a DevOps environment through the collaboration between software developers, operations team and business stakeholders.

2. Build: Automating Code Integration and Compilation

The build stage is the process of compiling software, resolving dependencies and generating something deployable. The DevOps build practices pay much attention to automation and uniformity.

Read more

In case your organisation is working with legacy systems that have become too expensive to maintain, faces challenges of scalability or simply wishes to adopt cloud-first paradigm, this guide will provide a complete roadmap of moving on to AWS.

We’ll break down complex concepts into easy steps and provide practical advice you can implement immediately.

So without further ado, let’s get started.

Subscribe now

Step 1: Understanding Cloud Migration

Now, before we take a look into the technical details, it is good to know what cloud migration actually means for your business.

Cloud migration is a process in transitioning your digital assets, applications, databases, and IT processes that were previously found on your on-premises data-center to cloud-based infrastructure. These cloud infrastructure are usually provided by cloud vendors. Big names include AWS, Azure, GCP, etc.

There are several types of cloud migration strategies we can follow:

Rehosting or “Lift and Shift”

Rehosting is simply re-deploying your applications in the cloud without much adjustments. Performs well with applications which do not require immediate optimization.

Re-platforming

It involves making minor adjustments to your applications to take advantage of cloud without changing the core architecture. For example, you might switch from a self-managed database to Amazon RDS.

Refactoring (or re-architecting)

It means redesigning your applications to be cloud-native, taking full advantage of cloud services and scalability features.

Repurchasing

Repurchasing means replacing your existing application with a cloud-based Software-as-a-Service (SaaS) solution. Instead of migrating and maintaining your own system, you subscribe to a managed service that delivers similar functionality. This is commonly seen when companies move from self-hosted email servers to services like Microsoft 365 or Google Workspace, or from custom CRM systems to SaaS platforms.

Retaining

Retaining means you decide to keep certain applications exactly where they are, usually on-premises, instead of moving them to the cloud right away. Not every system needs to be migrated. Some applications may be tightly coupled to physical hardware, subject to strict regulatory requirements, or simply not worth the migration cost at the moment. In other cases, the application may still be performing well and delivering business value without issues.

Retiring

Retiring involves decommissioning applications that are no longer useful or valuable to the business. During pre-migration assessments, many organizations discover redundant systems, outdated tools, or applications that are barely used. Migrating these systems would waste time and money.

A lot of the most successful migrations use a combination of these strategies, depending on each application’s specific requirements and business value.

Step 2: Pre-Migration Assessment

Launching and maintaining any successful cloud migration would include a careful analysis of your current environment.

This is a step that you can not underestimate, but by taking time now, you can save yourself a lifetime and issues further down the road.

To do this, begin by conducting an inventory of all of your IT assets. This does not only mean servers and applications but also databases, network settings, security policies, backup infrastructure and even documentation. It is during this step that many organizations learn things that they do not know. This might include such applications or systems as departments have installed without the IT knowledge.

Record the current performance metrics and dependencies of each application and system as well as its business criticality. A payroll processing application is obviously more important than an in-house application that is used by few people. The given business impact assessment will make you understand which systems should be migrated first and which must be planned with the strongest attention.

Better your planning and assessments are, less you will have risk of downtime and business loss during the migration process.

Focus especially on information flows between systems. The truth is that modern applications do not always work in isolation so you need to know about those dependencies in planning how you want to progress your migration. You need to develop a visual map that indicates how data moves in and out of your applications, databases and third party systems.

Compliance should not be bargained upon during this stage of assessment. There are certain rules concerning storage and handling of data in such industries as healthcare, finance, and government. There are many compliance certifications provided by AWS, however, you will have to find out all specifics of requirements regarding your business to plan implementation.

Step 3: Planning Your Migration Strategy

Now that you have assessed and gotten your act together you may devise an overall migration plan that best fits your organizational requirements and limitations.

Start with grouping your applications into waves of migration. The initial release must have shorter dependencies and less important applications that could be used as the training opportunities of your developers. Future waves will be able to address more intensive, company-essential systems as you develop cloud capabilities.

It may be advisable that you start with development environments and test environment before going live with your production systems. This will enable your team to experience AWS services at a less risky environment as well as save costs in the short term and increase developer productivity.

AWS Provide AWS Prospective Guidance for large migrations.

Make a complex schedule that takes into consideration systems dependencies. In case database A is dependent on database B, database B should be migrated first or there should be a way to keep the two databases connected while the migration occurs. Allocate time in your plan to deal with some unforeseen issues and testing.

Before actual migration work begins, you can organize a workshop within your organization to prepare your team for better understanding of migration. After migration, everything will not be same, your business dynamics changes, your team will be affected. So be prepare.

Build your cloud architecture design on this plan. It does not imply that you should settle on all the details but there should be a clear picture of your target state. Things such as high availability, disaster recovery, security, and cost optimization must be considered in the early days as opposed to being an afterthought.

Step 4: Setting Up Your AWS Environment

Properly configuring your AWS environment before beginning migration activities sets the foundation for security, cost control, and operational efficiency.

The next step is to use a multi-account strategy with AWS Organization. Even small companies appreciate the benefit of a physically distinct account (Development, Staging, Production) and business units. This segregation enhances security, eases the process of cost apportionment and minimizes the chances of mistaken alterations of production systems.

Security is vital. So start configuring Identity and Access Management (IAM) properly. Use the least privilege principle and only grant privileges to users and applications, just enough privileges to perform their tasks. Design access controls on the basis of roles within your organization and roles.

Install a good logging and monitoring facility at the earliest. AWS CloudTrail is advisable to enable it on every account and monitor API calls and changes. Using cloudwatch, Amazon monitors your applications and resources. The services provide the necessary support in troubleshooting, security-auditing and cost optimization.

Put cost controls in place so that will avoid budget surprises. AWS Cost Explorer and AWS Budgets assist you in keeping a tab on the expenditures and allow you to configure notifications in the event of overspend. You might want to consider using the AWS Cost Allocation Tags to measure expenditure according to project, department or application.

There is some careful planning that needs to be done when it comes to network design, particularly when you have some type of hybrid connectivity to on premise systems. Amazon VPC uses VPN or AWS Direct Connect to connect the isolated network environment created using Amazon VPC with your existing infrastructure in a secure and easy to use way.

It is proposed to begin infrastructure as code application with the help of AWS CloudFormation or Terraform or other popular one. This solution is the reproducibility, version control of your infrastructure and control in any number of environments.

Step 5: Data Migration Strategies

The most demanding and dangerous part of the cloud migration process is usually its data migration. The method of data flow is dependent on issues such as the amount of data to be moved, tolerable downtime and network bandwidth.

Online data transfer may be enough in the case of smaller datasets, or applications that have the potential to afford some outage-style downtime. AWS DataSync can optimize the process of transferring the large amount of information over the internet and has inbuilt optimization and verification processes.

AWS offline data transfer services may also be useful where the data is large or bandwidth is limited. AWS Snowball devices enable you to literally box off terabytes of data in order to ship it out to AWS without incurring internet bandwidth issues. AWS Snowmobile may be utilized in cases when the size of the data is really large, small enough for transfer through the use of a shipping-container-sized device and up to 100 petabytes of information.

Migration of databases is especially important because data has to be kept consistent and downtime must be kept as minimal as possible. AWS Database Migration Service (DMS) allows both homogeneous migrations such as Oracle to Oracle as well as heterogeneous migrations such as Oracle to PostgreSQL. The service supports either one-time migration, or continuous replication to achieve minimal downtime.

Design your data migration steps. First use non-critical data and systems to audit your processes and tools. In cases of important databases, you can resort to a staged implementation: You first install replication to AWS and then redirect the production.

Each migration step should have data validation built into it. Do not think that data has been successfully transferred without checking. Compare record and checksum numbers and sample data between source system and destination system.

Reflect on your migration period synchronization needs of data. Other systems may be software whose run needs to continue over weeks or months, needing bi-directional synchronisation or controlled handling of conflicts.

Step 6: Application Migration Process

Application migration strategies are very different based on the business need, nature of application architecture, as well as technological stack.

AWS Application Migration Service may help you do this easily when the workloads are appropriate to use lift-and-shift migration, by making real-time copies of your servers in a cloud in AWS. Such a strategy will have minimal alterations to the application, although it may not get the most out of the cloud.

Replatforming strategies are also used frequently in web applications. AWS Elastic Beanstalk offers simplified deployment and management capabilities that may be of interest instead of running your web servers on a virtual machine, or Amazon ECS to run containerized applications.

Cloud application may need more aggressive refactoring of legacy apps. This might include decomposing monolithic applications into microservices, using cloud-native databases or moving some functions to a serverless computing platform with AWS Lambda.

Configuration of the applications is to be given special consideration during migration. Connection strings, paths to files and environment variables usually require modification of the cloud environment. You may consider the use of AWS Systems Manager Parameter Store or AWS Secrets Manager to address secure configuration management.

Step 7: Security and Compliance Considerations

Security in cloud is based on a shared responsibility model. AWS secures the infrastructure, you secure the application, the data andalse.

Read more

I’ll be honest. Most days, I care far more about what you can build than what’s listed on your résumé. But sometimes certifications become a deciding factor.

This week, I wanted to share the free, best resources that actually help you pass AWS exams.

Inside the issue, you will get:

• Proven, no-fluff list of AWS courses

• Official exam guides and real sample questions

• Success stories from other builders

• Some Exam Tips

Read more

In my previous article, I explained why you MUST learn Linux as a cloud builder. In this issue, I want share some of the best resources to get you started. These are the resources I use to stay upto date in Linux world.🐧

Every week, my inbox looks the same. “Do you have free cloud training?” “Can you share exam vouchers?” “Can you mentor me for AWS or DevOps?”

I try to help as much as I can. I really do. But replying 1:1, giving real guidance, and sharing quality resources at scale is hard, and free alone isn’t sustainable. That’s why I have introduced The Cloud Handbook Scholarships to 100 builders. 50% OFF on yearly subscriptions.

GET THE SCHOLARSHIP

*Note: only few seats left.

🧑‍🏫 Courses

1. Introduction to Linux (LFS101)

The course Introduction to Linux (LFS101), provided by the Linux Foundation, is a comprehensive beginner-level program designed to give you a solid working knowledge of the Linux operating system. It is one of the most popular introductory courses in the industry and is available for free.

2. Linux Essentials by CISCO Networking Academy

The Linux Essentials course, offered by the Cisco Networking Academy (in partnership with NDG - Network Development Group), is an entry-level program specifically designed to prepare you for the LPI (Linux Professional Institute) Linux Essentials Professional Development Certificate.

3. Linux Journey (Learn by doing)

Linux Journey (hosted by LabEx) is a popular, community-driven curriculum that was recently integrated into the LabEx platform. It is famous for its "gamified" approach to learning, breaking down complex topics into small, digestible "snacks."

• Learn Linux for FREE (full course)

📚 Books (Download PDF)

If you are someone who prefer learning by reading, here are some free books

• Linux Fundamentals

• Introduction to Linux —A Hands-on Guide

• The Ultimate Linux Newbie Guide

▶️ YouTube

1. Learn Linux TV (my favorite)

2. The Linux Experiment

3. NetworkChuck

📝 Blogs Posts

1. https://www.linuxjournal.com/

2. https://www.tecmint.com/

3. https://www.linuxtoday.com/

4. https://www.omgubuntu.co.uk/

5. https://leanpub.com/read/the-tao-of-tmux

6. Linux.com

7. nixCraft

Some past posts from The Cloud Handbook.

Thanks for reading The Cloud Handbook. See you in the next one!

- Kisan

Share

Welcome to this new FinOps series of The Cloud Handbook. In each series, we will talk about all things FinOps and share the best resources to help you learn FinOps. The idea is to share how important the cloud cost is for builders like you.

Cloud bills can spiral quickly, but most organizations have straightforward opportunities to reduce spending without sacrificing performance.

This week, I am sharing the ten most effective cost optimization strategies you can implement today.

1. Clean Up Unused Resources

This is most common reasons you have a big cloud cost bill.

Your cloud environment accumulates waste over time. Detached EBS volumes continue charging you even when no instance uses them. Unassociated Elastic IPs cost money while sitting idle.

Old snapshots pile up from deleted instances. Run regular audits to identify and remove these resources.

A simple script checking for unused resources weekly can save hundreds to thousands per month. Do it now.

2. Right-Size Your Instances

Most instances run with excess capacity. Your t3.large instance might average 20% CPU utilization when a t3.medium would handle the load perfectly.

Use CloudWatch metrics to analyze actual resource consumption over 30 days.

Look at CPU, memory, network, and disk metrics during peak hours.

Moving just ten oversized instances to appropriate sizes can reduce compute costs by 30-50%.

3. Switch to ARM-Based Instances

ARM processors like AWS Graviton deliver the same performance as x86 instances at significantly lower prices.

Graviton instances offer up to 40% better price performance for most workloads.

Many modern applications and containers run on ARM without modification. Test your workloads on ARM instances to verify compatibility, then migrate production traffic gradually.

4. Implement Storage Lifecycle Policies

Data sitting in Standard S3 storage might not need instant access. Analyze access patterns to identify objects untouched for 30, 60, or 90 days.

Move infrequently accessed data to S3 Infrequent Access or Glacier Instant Retrieval.

These tiers cost 50-80% less while maintaining quick retrieval when needed.

Set up automatic lifecycle rules so data transitions without manual intervention.

5. Optimize Data Transfer Architecture

Cross-AZ data transfer fees add up quickly, especially for chatty microservices or databases with replicas. Review your architecture to minimize unnecessary cross-AZ traffic.

Consider deploying stateless services in a single AZ when high availability allows. For databases, use read replicas strategically rather than replicating across every zone. Monitor data transfer costs in Cost Explorer to identify the biggest sources.

6. Use Spot Instances for Fault-Tolerant Workloads

Spot instances cost 70-90% less than on-demand pricing. They work perfectly for stateless applications like CI/CD runners, batch processing jobs, and rendering tasks.

Kubernetes cluster autoscaling can mix spot and on-demand nodes. Configure your workloads to handle interruptions gracefully. Even using spot instances for 30% of your compute capacity delivers substantial savings.

7. Schedule Non-Production Environments

Development and staging environments rarely need to run 24/7. Stopping instances overnight and on weekends reduces runtime by 70% or more.

Use Lambda functions or automation tools to shut down environments at 6 PM and restart them at 8 AM on weekdays. Tag resources by environment to automate scheduling policies. This single change often cuts non-production costs in half.

8. Commit with Savings Plans or Reserved Instances

If you have predictable baseline usage, commitment-based pricing saves 30-70% compared to on-demand rates. Savings Plans offer more flexibility than Reserved Instances because they apply across instance families, sizes, and regions.

Start by analyzing your stable workloads over the past 90 days. Commit to covering 60-70% of your baseline usage, leaving room for growth and experimentation on on-demand pricing.

9. Tune Kubernetes Resource Requests and Limits

Kubernetes clusters waste significant resources when pods request more CPU and memory than they actually use. This slack means you provision more nodes than necessary.

Review actual resource consumption using metrics from Prometheus or CloudWatch Container Insights. Set requests based on real usage plus 20% headroom. Properly configured requests and limits can reduce cluster costs by 30-40%.

10. Replace NAT Gateways with VPC Endpoints

NAT Gateways cost money for both the service itself and data processing. When your private subnets only need to access AWS services like S3 or DynamoDB, VPC Endpoints eliminate NAT Gateway charges entirely. A single NAT Gateway costs about $32 monthly plus $0.045 per GB processed. VPC Endpoints cost $7.20 monthly with no data processing fees. For high-traffic applications, this switch saves thousands monthly. This blog post from Towards AWS explains everything

Free Best Courses

Read more

Almost every week, my inbox looks the same.

“Do you have free cloud training?”
“Can you share exam vouchers?”
“Can you mentor me for AWS or DevOps?”

I try to help as much as I can. I really do.
But replying 1:1, giving real guidance, and sharing quality resources at scale is hard, and free alone isn’t sustainable.

That’s why I’m doing something different.

🎓 The Cloud Handbook (TCH) Scholarship

I’m offering a 50% scholarship to the next 100 serious cloud builders who want to level up their careers.

What you get for just $30/year (50% OFF):

• 🤝 Practical 1:1 guidance (career or technical)

• 📚 Full access to all Cloud Handbook resources

• 🧠 Upcoming books, guides, and deep dives

• ☁️ Real-world cloud, DevOps, and system design insights
  No fluff. No recycled content. Just what actually works.

This isn’t for everyone.
It’s for builders who are tired of random tutorials and want a clear path into Cloud.

⏳ Only 100 scholarships. Once they’re gone, they’re gone.

ENROLL NOW

* I will turn off this discount once we reach 100 signups

Keep learning and building.

- Kisan

Some read from the past

Learning Cloud, DevOps, and AI shouldn’t be hard and expensive in 2026. The biggest problem with learning Cloud in 2026 isn’t a lack of information—it’s the noise.

This isn’t just a list; it’s a database designed to take you from ‘Hello World’ to a ‘Great Cloud Engineer.’ This is where you find great learning resources. The list is long; take your time. Update every week.

Stop scrolling. Start building.

1. Amazon Web Services (AWS)

AWS provides a massive library of free training through its official portals.

Read more

CloudBurn analyzes your Terraform or AWS CDK infrastructure changes and automatically posts cost estimates in pull requests. Catch expensive mistakes during code review instead of discovering them weeks later on your AWS bill.

LEARN MORE

I always recommend learning the Basics of Linux to anyone who is getting started in Cloud. Linux runs most of the cloud workload, and you will always find yourself troubleshooting or deploying on Linux machines.

In this issue, I wanted to share why you should learn Linux as a Cloud Engineer and some of the best resources to get started.

Free resources and references are mentioned at the end of this issue. So read all the way down.

Let’s get started…

1. Linux Powers Nearly Half of All Cloud Workloads

Linux powers 49.2% of all cloud workloads globally as of Q2 2025.

This alone should convince you to learn Linux.

Think about that for a moment. Every other workload running in the cloud is Linux-based. When you’re troubleshooting a production issue or optimizing costs for your infrastructure, there’s nearly a 50/50 chance you’re dealing with a Linux system.

It’s the foundation of modern cloud computing. AWS EC2 instances are 83.5% Linux-based, Azure reports 61.8% Linux VM usage, and Google Cloud sees 91.6% Linux VMs. If you’re working in the cloud, you’re working with Linux whether you realize it or not.

2. Kubernetes and Containers Run on Linux

Linux is the foundation of both of these technologies. If you understand Linux, learning k8s or Docker should be easy.

I have written about how container technology works under the hood in the following issue:

• 78% of all Kubernetes clusters globally run on Linux distributions

• 75% of Docker containers are deployed on Linux environments

• 96.4% of production Kubernetes clusters run on Linux

Container orchestration isn’t the future anymore. It’s the present. 80% of organizations deployed Kubernetes in production environments as of 2024, and projections show enterprise adoption will exceed 90% by 2027.

Every time you deploy a containerized application, you’re working with Linux. Every pod you scale, every service mesh you configure, every microservice you deploy, it all runs on Linux. Without Linux knowledge, you’re essentially flying blind in the container ecosystem.

3. The Linux Job Market Is Red Hot

• 93% of employers report difficulty finding qualified open-source talent

• Linux systems administrators earn a median annual salary of $96,800, with top earners exceeding $150,320

• 62,808 active Linux engineer positions and 56,604 Linux administrator openings are currently available in the United States

• 110,000+ Kubernetes-related job listings on LinkedIn as of 2025

The demand far exceeds the supply. 61% of hiring managers actively seek Linux skills, and cloud platform expertise combined with Linux knowledge adds 15-25% salary premiums.

When DevOps engineers with Linux expertise command salaries between $115,000 and $179,000 (with top performers earning over $200,000 at major tech companies), it’s clear that this skill set translates directly into career advancement and compensation.

4. Developers Are Already Using It

Many developers worldwide report using Linux either as a primary or secondary OS. If you are still not sure, you can use Linux on WSL. This is a great resource to get started.

Your peers and colleagues are already working in Linux environments. Development teams are standardizing on Linux for consistency between development and production. If you’re the one engineer who doesn’t know their way around a Linux terminal, you’re creating bottlenecks for yourself and your team.

Ubuntu demonstrates near-identical adoption rates between personal (27.8%) and professional (27.7%) developer usage, indicating that developers are choosing Linux not just because they have to, but because it makes their work more efficient.

5. Every Major Cloud Provider Runs on Linux

• AWS holds approximately 30% global cloud infrastructure market share as of Q3 2025

• Azure holds 20% market share

• Google Cloud Platform holds 13% market share

Together, the Big Three control over 60% of the global cloud infrastructure market, and Linux is the backbone of all three platforms. AWS EC2 instances are 83.5% Linux-based, with Amazon Linux, Ubuntu, and RHEL leading.

No matter which cloud certification you pursue, AWS Solutions Architect, Azure Administrator, or Google Cloud Engineer, you’ll be working extensively with Linux systems. The cloud providers have made their choice: Linux is the operating system of the cloud.

6. The Linux Market Is Exploding

• The global Linux operating system market reached $21.97 billion in 2024 and is projected to grow to $99.69 billion by 2032

• The server operating system market reached $22.28 billion in 2025 and is expected to grow at 8.90% CAGR to reach $34.12 billion by 2030

• Linux holds 44.8% server operating system market share as of 2024

Organizations are migrating to Linux for cost efficiency, flexibility, and performance. 72.6% of Fortune 500 companies run mission-critical workloads on Linux.

The momentum behind Linux is undeniable. As cloud computing continues to grow (projected to reach nearly $6 trillion by 2035), Linux will grow right alongside it.

7. DevOps Platforms Rely Overwhelmingly on Linux

• DevOps platforms rely on Linux for 82% of their infrastructure

• The DevOps market is projected to expand from $13.2 billion in 2024 to $81.1 billion by 2028

• DevOps positions rank second at 51% of organizational priorities

Every CI/CD pipeline you build, every infrastructure-as-code template you write, every automated deployment you configure—the underlying systems are running Linux. The most popular DevOps tools (Docker, Kubernetes, Jenkins, Terraform, Ansible) were all built with Linux in mind and work best on Linux systems.

Cloud platform expertise adds 15-25% premium to DevOps salaries, with AWS Solutions Architect being most valuable. But you can’t effectively use cloud platforms without Linux knowledge.

8. Linux Dominates High-Performance and Enterprise Computing

• 100% of the TOP500 supercomputers run Linux as of November 2024

• 64.9% of government data centers worldwide report Linux adoption

• Banking and financial services increased their Linux infrastructure footprint by 21.5% year-over-year

This complete dominance in supercomputing isn’t coincidental—it’s because Linux offers the customization, performance, and stability that critical systems demand. Government-funded HPC laboratories reported a 15.6% increase in Linux kernel customization in 2025.

When organizations need maximum reliability, performance, and control, they choose Linux. That includes the most demanding computing environments on the planet.

9. Container Technology Adoption Is Skyrocketing

• Over 90% of organizations are now using or evaluating containers in some capacity

• Gartner estimates over 95% of new digital workloads will be on cloud-native (mostly containerized) platforms by 2025

• The global application container market reached $5.85 billion in 2024, with projections indicating growth to $31.50 billion by 2030

• Docker maintains 87.67% market share in containerization, with over 108,000 companies utilizing the platform globally

Containerization has fundamentally changed how we deploy applications, and containers run on Linux. Even when you’re running Docker on Windows or Mac, those containers are running Linux inside.

The container market is experiencing 33.5% compound annual growth, and among IT professionals, container usage soared to 92%. This isn’t a trend you can ignore.

10. AI and Machine Learning Workloads Are Linux-Native

AI/ML workload adoption stands at 54%, with over 90% of surveyed teams expecting their Kubernetes AI workloads to increase within 12 months.

The AI revolution everyone is talking about? It’s running on Linux. TensorFlow, PyTorch, and other major ML frameworks are built for Linux environments. GPUs for AI training are optimized for Linux. Kubernetes clusters running AI workloads are on Linux.

As organizations race to integrate AI into their products and services, they’re building on Linux infrastructure. If you want to be part of the AI infrastructure revolution, you need to know Linux.

How Much Linux Should You Learn?

In my previous issue, I discussed what Linux concepts you should learn as a Cloud builder. Learn more here:

You don’t need to become a kernel developer, but you should be comfortable with:

• Command-line navigation: Moving around the filesystem, managing files and permissions

• System administration basics: Understanding users, processes, services, and system resources

• Networking fundamentals: Using tools like curl, netcat, ssh, and understanding ports and firewalls

• Package management: Installing and updating software with apt, yum, or other package managers

• Log analysis: Finding and interpreting logs with grep, tail, journalctl

• Shell scripting: Writing basic bash scripts to automate tasks

• Container basics: Understanding how Linux containers work and how to troubleshoot them

Start with the essentials and build from there. Real-world problem-solving will deepen your knowledge faster than any tutorial.

Here are the three most-read resources we published on The Cloud Handbook.

Resources to Get Started

• Introduction to Linux (LFS101)

• Learn Linux TV (my favorite)

• 10 Free Linux Books That Will Make You a Linux Master

• Learn Linux for FREE (full course)

Conclusion

If you are getting started in any cloud roles, my advice has always been the same. Learn Linux. It is an essential skill for Cloud Engineers.

See you in the next one!

- Kisan

References

• https://www.fortunebusinessinsights.com/linux-operating-system-market-103037

• https://sqmagazine.co.uk/linux-statistics/

• https://commandlinux.com/statistics/linux-container-kubernetes-adoption-statistics/

In this issue, let me walk you through 10 concepts that I think you must master to thrive in your Cloud career.

Let’s get started…

Read more

As we approach the end of the year, I’ve been reflecting on our progress in 2025. Analyzing what worked and identifying where we can improve. My goal for 2026 is simple: to make The Cloud Handbook the most valuable resource in your toolkit.

To show my appreciation for your support from the beginning, I’m offering a 50% discount on Yearly Subscriptions through the holiday season. The offer expires in 24 hours.⏰

🎁 Claim your Discount🎁

As a paid member, you’ll lock in full access to all exclusive deep-dives and receive future digital books I publish in 2026. Thank you for being a part of this community. Also, feel free to reply to this email or DM me for any kind of advice or feedback.

Happy Holidays,

Kisan

Recent Posts

This week, I am sharing the 10 best hands-on cloud projects I recommend. I have structured these by difficulty level and, crucially, included “Resume Gold,” a specific bullet points you can copy-paste to describe your work professionally in your resume.

Level 1: The Foundation (Beginner)

Focus: Core services, static hosting, and basic networking.

#1. The “Cloud Resume Challenge.”

This is the gold standard for a reason. You host your resume as a static site, but with a twist: it must use HTTPS, a custom domain, and a visitor counter stored in a database, updated via an API triggered by a script.

• The Architecture: S3 (Frontend) → CloudFront/CDN → API Gateway → Lambda/Functions → DynamoDB.

• Tech Stack: HTML/CSS, Python/Node.js, Terraform/SAM (Infrastructure as Code).

• Sample Solutions:

  • https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html

  • https://dev.to/gbenga700/hosting-your-static-website-on-aws-s3-using-terraform-iac-11hh

• Resume Gold:

  • Designed and deployed a static web application on AWS.

  • Implemented Infrastructure as Code (IaC) using Terraform to provision resources, eliminating manual configuration.

If you need any help with any of the projects, reach out to me via chat.

Read more

If you are a serverless builder like me, you would know serverless is cheap, fast, and scales endlessly most of the time.

Today, let’s talk about Lambda costs because that $200/month bill can quickly become $20,000 if you’re not careful.

Here’s the thing about Lambda pricing: it seems simple until it isn’t. You pay for requests and duration.

But the real cost drivers are hiding in plain sight: concurrency spikes, big package sizes, and functions sitting idle waiting for database queries, etc.

A function that runs for 500ms instead of 200ms doesn’t sound like much, but multiply that by 10 million invocations, and you’re paying hundreds of extra dollars every month.

In this issue, I’m sharing 10 practical tips that can cut your Lambda costs significantly. These strategies will help you optimize without sacrificing performance.

Let’s get started…

Tip 1: Right-Size Your Function Memory

This is counterintuitive, but hear me out: increasing your Lambda memory allocation can actually reduce your total cost.

Why? Because memory directly affects CPU power and network throughput. A function with 512MB might take 1000ms to complete, while the same function with 1024MB finishes in 400ms. Since Lambda charges for GB-seconds, you often come out ahead by going bigger.

How to find the sweet spot: Run your function at different memory settings (128MB, 256MB, 512MB, 1024MB, etc.) and measure the actual execution time. Calculate the cost for each configuration using this formula:

Cost = (Memory in GB) × (Duration in seconds) × (Price per GB-second)

The lowest result is your winner.

This is a good read from the official AWS blogs on how memory increases the performance of Lambda functions.

Tip 2: Reduce Cold Starts

Cold starts happen when Lambda needs to spin up a new execution environment. They’re slow, and they cost you money.

In recent announcements, AWS Lambda standardizes billing for INIT Phase, AWS has started to charge for cold start. Before, it wasn’t the case.

Two strategies that work:

• Provisioned Concurrency: Keeps a set number of execution environments warm and ready. Only use this for critical, latency-sensitive functions. It costs significantly more than on-demand.

• Choose the right runtime: Interpreted languages like Python and Node.js have faster cold starts than compiled languages like Java. If cold starts are killing you, consider switching runtimes.

Tip 3: Use AWS Lambda Power Tuning

Stop guessing at the right memory configuration. Let automation do it for you.

The AWS Lambda Power Tuning tool runs your function at multiple memory levels, measures performance, and tells you the optimal configuration for either cost or speed. It’s an open-source Step Functions state machine that saves hours of manual testing.

Run it once per function, implement the recommendations, and watch your costs drop.

GitHub Link: https://github.com/alexcasalboni/aws-lambda-power-tuning

Tip 4: Keep Your Package Size Small

Every megabyte in your deployment package adds to cold start time, which adds to execution duration, which adds to your bill.

Quick wins:

• Remove unused dependencies (do you really need that entire SDK?)

• Use Lambda Layers for shared code across multiple functions

• Minify and tree-shake your code if you’re using JavaScript

• Exclude dev dependencies from production builds

Aim for deployment packages under 10MB when possible. Your cold starts will thank you.

Tip 5: Optimize Function Duration

Lambda charges by the millisecond, so every optimization counts.

Move the right workloads elsewhere:

• Heavy data processing → AWS Fargate or ECS

• Complex orchestration → Step Functions

• High-throughput data operations → DynamoDB Streams or Kinesis

For workloads that stay in Lambda:

• Use async processing when you don’t need immediate results

• Batch operations instead of processing items one at a time

• Offload CPU-intensive tasks to dedicated compute services

The goal isn’t to avoid Lambda—it’s to use Lambda for what it does best: short, event-driven tasks.

Tip 6: Use Graviton2/3 Lambda Functions

ARM-based Graviton processors cost 20% less than x86 and often deliver better performance.

Switching is usually as simple as changing your function architecture from x86_64 to arm64. Most modern runtimes and libraries support ARM without any code changes.

Quick compatibility check: Test your function on ARM in a dev environment first. 99% of the time, it just works.

Tip 7: Limit Over-Invocation

Unnecessary invocations are silent budget killers.

Common culprits:

• Aggressive retries: Lambda retries failed async invocations twice by default. Add a Dead Letter Queue (DLQ) to catch persistent failures instead of retrying forever.

• Duplicate triggers: Check your event source mappings. Is the same message triggering multiple functions?

• No filtering: Use event filtering on SQS, SNS, and EventBridge to prevent functions from running when they don’t need to.

One misconfigured retry policy can turn a $50/month function into a $500/month disaster.

Tip 8: Cache Smartly

Stop making the same database queries over and over.

Three caching strategies:

1. Lambda Extensions: Cache data in-memory between invocations (works for warm containers)

2. Amazon RDS Proxy: Manages connection pooling so you’re not creating new database connections on every invocation

3. DynamoDB DAX: Microsecond latency for DynamoDB reads with built-in caching

Bonus tip: Reuse database connections across invocations by initializing them outside your handler function. Lambda containers stay warm for several minutes, so you’ll save connection overhead on subsequent invocations.

Tip 9: Use Step Functions for Long Workflows

If your Lambda function runs for more than a minute, you’re probably paying for a lot of idle time.

Step Functions let you break long processes into smaller tasks. Instead of one function running for 5 minutes (and billing for all 5), you run five 1-minute functions with Step Functions coordinating between them. You only pay for actual compute time, not waiting time.

Perfect for workflows that involve external API calls, approval steps, or processing large datasets in stages.

Tip 10: Monitor with CloudWatch + Cost Explorer

You can’t optimize what you don’t measure.

Set up monitoring for:

• Function duration (watch for trends over time)

• Error rates (errors that trigger retries = wasted money)

• Concurrent executions (are you hitting limits unexpectedly?)

• Cost per function (identify your biggest spenders)

Set CloudWatch alarms for unusual spikes in invocations or duration. Catching a runaway function early can save thousands.

Pro tip: Use AWS Cost Explorer’s “Group by” feature to break down Lambda costs by function name. You’ll quickly spot which functions need optimization.

Keep Optimizing

Lambda’s pay-per-use model is powerful, but only if you use it smartly. Start with the tips that apply to your highest-traffic functions, measure the impact, and iterate.

Resources to bookmark:

• AWS Lambda Pricing Calculator – Model costs before deployment

• AWS Lambda Power Tuning Tool – Automated optimization

• Understanding the Lambda execution environment lifecycle

• Understanding and Remediating Cold Starts: An AWS Lambda Perspective

Conclusion

Got a Lambda cost challenge you’re wrestling with? Hit reply and tell me about it. I read every response and often feature reader questions in future issues.

Until next time, keep building in the cloud.

We crossed 10,000+ subscribers this week. And I wanted to take a moment to celebrate with you all.🥳

Thank you for reading The Cloud Handbook and supporting my work.

Also, I get asked a lot about AWS credits, exam vouchers, and resources. Although I am unable to help every one of you, I am giving away $500 AWS Credits to one lucky paid subscriber (only). This way, I can ensure you are serious about learning and building. The winner will be announced in two weeks from now.

Upgrade Now

Let’s talk about my upcoming book now.

When I first started learning cloud, one thing I struggled a lot with was Linux. Linux is a must-have skill for cloud builders like us.

More than 90% of cloud runs on Linux. No matter what, you can not skip Linux in the Cloud.

The book is titled Linux Essential for Cloud — Enough Linux to Excel in Your Cloud Career.

So far, we are making so much progress in the book. I am aiming to launch it by the end of December and am looking for advice and feedback from you.

Here are the skills I expect you to learn from this book. These are the non-negotiable Linux skills for Cloud Builders:

• Comfort with Linux Terminal

• Package Management

• System Services and Daemon

• Networking Fundamentals

• User, Group, and Permission Management

• Storage and File System in Linux

• Logs and System Monitoring

• Shell Scripting

• Working with Git and SSH

• Container and Linux Internals

• Security Best Practices

The book is very brief and skips most of the advanced part. I have written this book to be more practical rather than too theoretical.

Here’s the first look at the Table of Contents.

Your feedback helps shape this book.

PART I — Getting Started With Linux

Chapter 1: Understanding Linux

1.1 What is Linux? – The operating system powering cloud environments.
1.2 Why Linux Dominates the Cloud – Stability, security, and open-source culture.
1.3 Linux Distributions Explained – Ubuntu, Amazon Linux, CentOS, and others.

Chapter 2: Setting Up Your Linux Environment

2.1 Using Linux on Your Local Machine – WSL, VM, or dual boot.
2.2 Spinning Up a Cloud Server (EC2) – Beginner-friendly AWS setup.
2.3 Connecting to Linux Servers (SSH Basics) – Cloud-native login workflow.

Chapter 3: Navigating the Linux Shell

3.1 The Command Line Interface (CLI) – How the shell works.
3.2 Essential Commands (ls, cd, pwd, mkdir, rm…) – Everyday operations.
3.3 File and Directory Structure – /home, /var, /etc, /tmp, and cloud importance.
3.4 Working With Files (nano, vim, cat, grep) – Reading and editing logs, configs.

PART II — Core Linux Skills for Cloud Engineers

Chapter 4: Users, Permissions & Security Basics

4.1 User & Group Management – Adding engineers, automation accounts.
4.2 Permissions & Ownership – chmod, chown, umask, and cloud security.
4.3 Sudo & Privilege Management – Least privilege and secure operations.

Chapter 5: Processes & System Monitoring

5.1 Understanding Linux Processes – Foreground, background, daemons.
5.2 Monitoring Tools – top, htop, ps, systemd.
5.3 Troubleshooting Performance – CPU, RAM, disk, network bottlenecks.

Chapter 6: Package Management

6.1 APT, YUM, DNF Basics – Installing and updating software.
6.2 Managing Dependencies – Real-world cloud use cases.
6.3 Hardening & Patching Servers – Security patching for production.

Chapter 7: Storage, Filesystems & Disks

7.1 Understanding Volumes & Partitions – Cloud storage concepts.
7.2 Mounting & Managing Filesystems – ext4, xfs, nfs.
7.3 AWS Examples: EBS, Instance Store, S3 Mounting – Practical cloud workflows.

Chapter 8: Networking Fundamentals

8.1 IP Addressing, DNS, Routing – Concepts every cloud engineer must know.
8.2 Using Network Tools (ss, netstat, curl, ping) – Testing connections.
8.3 Firewall Basics (ufw, iptables) – Securing cloud instances.
8.4 AWS Examples: Security Groups, VPC Flow Logs – Cloud-native networking.

Chapter 9: System Logs & Observability

9.1 Understanding Linux Logs – auth, syslog, app logs.
9.2 Using journalctl, dmesg, tail – Root-cause analysis.
9.3 Shipping Logs to the Cloud – CloudWatch, ELK, OpenSearch basics.

PART III — Automation, Scripting & DevOps Foundations

Chapter 10: Shell Scripting for Cloud Engineers

10.1 Bash Scripting Basics – Variables, loops, conditions.
10.2 Automating Linux Tasks – Backups, updates, checks.
10.3 Writing Scripts for Cloud Automation – EC2 bootstrap scripts, logs.

Chapter 11: Linux & Git Integration

11.1 Installing & Using Git on Linux – Core commands.
11.2 SSH Keys & GitHub – Secure authentication.
11.3 Version Control in Cloud Projects – IaC, configs, deployments.

Chapter 12: Linux in DevOps & CI/CD

12.1 Why DevOps Needs Linux – Servers, pipelines, automation.
12.2 CI/CD on Linux – GitHub Actions, GitLab, CodePipeline examples.
12.3 Deploying Code to Linux Servers – Blue-green & zero-downtime basics.

PART IV — Cloud-Focused Linux Skills

Chapter 13: Linux for Containers & Docker

13.1 How Containers Use Linux – Namespaces, cgroups.
13.2 Docker Installation & Basics – Images, containers, volumes.
13.3 Running Apps in Containers – Cloud-native workflows.

Chapter 14: Linux for Kubernetes

14.1 Why Kubernetes Needs Linux – Nodes, pods, networking.
14.2 k3s & Minikube Setup – Beginner-friendly cluster.
14.3 Deploying Workloads to Kubernetes – Simple hands-on example.

Chapter 15: Security & Hardening for Cloud Servers

15.1 SSH Hardening, Key Management – Avoiding security breaches.
15.2 Firewall Rules & Server Isolation – Defense in depth.
15.3 CIS Benchmarks & Cloud Best Practices – Compliance basics.

Chapter 16: Cost Optimization With Linux

16.1 Spot Instances, Right-Sizing, Auto-Tuning – Linux performance impacts.
16.2 Storage Optimization – Clean logs, reduce unused volumes.
16.3 Efficient Compute Usage – CPU scaling and monitoring.

PART V — Hands-On Cloud Project

Chapter 17: Build a Complete Linux-Based Cloud Application

17.1 Project Overview – Simple app + EC2 + Nginx + database + logging.
17.2 Deploy EC2 and Configure Linux – SSH, users, firewall, packages.
17.3 Deploy and Configure Nginx – Reverse proxy, SSL.
17.4 Connect to a Managed Database – RDS example.
17.5 Containerize the App – Build, push, deploy.
17.6 Set Up Observability – CloudWatch logs, metrics.
17.7 Automate Deployment – CI/CD pipeline.
17.8 Optimize & Harden – Security and cost tips.

Chapter 18: Real-World Scenarios & Troubleshooting

18.1 Fixing SSH Issues
18.2 Fixing Disk/Storage Alerts
18.3 Fixing High CPU/Memory
18.4 Fixing Network Connectivity Problems

Stay in the Loop

Although these are the topics I have covered so far, I will be editing heavily, so there might be changes in the final version. I would love to hear your feedback on what should be added, removed, and so on. Feel free to reply to this email, comment below, or DMs.

Thanks for reading. See you at the next one. Keep learning and building.

I never planned to become an AWS Community Builder. In fact, when I first started writing about AWS cloud, it was mostly for myself. To document what I was learning, to share my experiments, and to help anyone out there who was stuck the same way I once was.

Read more

Let’s get started with re:Invent announcements.

Upgrade to Paid

AWS Re:Invent 2025 Announcements

Here are some of the announcements on re:Invent 2025 so far.

• Introducing AWS Lambda Managed Instances: Serverless simplicity with EC2 flexibility

  AWS Lambda Managed Instances, a new capability you can use to run AWS Lambda functions on your Amazon Elastic Compute Cloud (Amazon EC2) compute while maintaining serverless operational simplicity. This enhancement addresses a key customer need: accessing specialized compute options and optimizing costs for steady-state workloads without sacrificing the serverless development experience you know and love.

• Introducing AWS Transform custom: Crush tech debt with AI-powered code modernization

  AWS Transform custom, a new agent that fundamentally changes how organizations approach modernization at scale. This intelligent agent combines pre-built transformations for Java, Node.js, and Python upgrades with the ability to define custom transformations. By learning specific transformation patterns and automating them across entire codebases, customers using AWS Transform custom have achieved up to 80% reduction in execution time in many cases, freeing developers to focus on innovation.

  You can define transformations using your documentation, natural language descriptions, and code samples. The service then applies these specific patterns consistently across hundreds or thousands of repositories, improving its effectiveness through both explicit feedback and implicit signals like developers’ manual fixes within your transformation projects.

• Announcing Amazon EKS Capabilities for workload orchestration and cloud resource management

  Amazon Elastic Kubernetes Service (Amazon EKS) Capabilities, an extensible set of Kubernetes-native solutions that streamline workload orchestration, Amazon Web Services (AWS) cloud resource management, and Kubernetes resource composition and orchestration. These fully managed, integrated platform capabilities include open source Kubernetes solutions that many customers are using today, such as Argo CD, AWS Controllers for Kubernetes, and Kube Resource Orchestrator.

• Introducing Amazon Route 53 Global Resolver for secure anycast DNS resolution (preview)

  Amazon Route 53 Global Resolver, a new Amazon Route 53 service that provides secure and reliable DNS resolution globally for queries from anywhere (preview). You can use Global Resolver to resolve DNS queries to public domains on the internet and private domains associated with Route 53 private hosted zones.

• AWS Clean Rooms launches privacy-enhancing dataset generation for ML model training

  Train ML models on sensitive collaborative data by generating synthetic datasets that preserve statistical patterns while protecting individual privacy through configurable noise levels and protection against re-identification.

What I'm Reading this Week

This week, I am experimenting with AWS Deadline Cloud. Weird name, right? I am working with a client who uses AWS to render heavy media. For this, AWS Deadline Cloud is a perfect solution. Here are some resources I have been using:

• Developing AWS Deadline Cloud on Open Job Description: Balancing Open Sources and Commercial Offerings

• AWS Deadline Cloud Documentation

• Portable and Open Render Job Specifications - Pauline Koh, AWS

• OpenJobDescription

• AWS Deadline Cloud Github resources

My friend Tobias compiled the top 15 AWS pre:Invent announcements.

• AWS pre:Invent 2025 - Top 15 Announcements

Some other readings:

• How You Do It Matters

• AWS Best Practices Are Dangerous. Here Are the Real Best Practices in 2025.

• The Complete Guide to Migrating Your EKS Cluster to Auto Mode

• EKS Networking Deep Dive: VPC CNI, Pod ENIs, IP Exhaustion, and Best Practices

Hands-on & How-tos

I am a big fan of Serverless. This week, I have curated these two workshops just for you. Get your hands dirty. And let me know if you have any questions.

• Building applications with a serverless mindset

  This workshop is intended for developers and architects that are building Serverless applications and want to learn how to use direct integrations. Once you complete the workshop, you will be familiar with direct integrations and how to use them.

• The Serverlesspresso workshop!

  

  In this workshop, you will build the serverless backend that supports Serverlesspresso. You will then test your application using provided front-end applications.

Tools Worth Trying

• AWS FinOps Dashboard

  

  A terminal-based AWS cost and resource dashboard built with Python and the Rich library. It provides an overview of AWS spend by account, service-level breakdowns, budget tracking, and EC2 instance summaries.

Book of the Week

Serverless Development on AWS: Building Enterprise-Scale Serverless Solutions

The adoption of serverless is on the rise, but until now, little guidance has been available for development teams that want to apply this technology on AWS. This definitive guide is packed with architectural, security, and data best practices and patterns for architects and engineers who want to build reliable enterprise-scale serverless solutions.

From Social Media

Stay in the Loop

If you found something worth sharing, reply to this email. I might feature it next time. Any feedback and contributions are appreciated.

Upgrade to Paid

I’m not a big fan of reminder emails like this.

But today is the final day to upgrade to The Cloud Handbook at $40/year ($3/month) for the whole of 2026, and I know many of you have been meaning to upgrade but just haven’t gotten around to it.

So consider this a friendly reminder.

If you’ve been learning from the deep dives, diagrams, and weekly breakdowns, now’s the best moment to join the paid side and support my work.

Upgrade here:

GET 50% OFF for 1 year

Thank you to everyone who subscribed.

See you inside!

—Kisan

Share

If you’ve been following The Cloud Handbook for a while, you already know I publish deep-dive breakdowns on Cloud, DevOps, Containers, System Design, AWS tips, and real-world architecture.

Today, you can unlock the full premium experience at a massive discount.

🎁 Black Friday Deal — 50% Off Premium Access

Here’s what you get when you upgrade:

• In-depth Cloud & DevOps breakdowns

• Architecture diagrams & cheatsheets (Lambda, S3, VPC, Containers, Serverless patterns)

• Systems Design deep dives

• Access to the growing Cloud Community

• Early access to new guides, tools & templates

• Curated Cloud and DevOps Jobs

⏳ Limited-Time Offer

This deal is available for a very short window. Once Black Friday ends, everything returns to its regular price.

If you’ve ever thought of joining the premium side, this is the best time.

Get Black Friday 50% OFF

💙 What our Readers are saying.

Get Black Friday 50% OFF

Thank you for reading The Cloud Handbook and supporting my work. Every upgrade helps me spend more time creating high-quality Cloud content for the community.

See you inside!
—Kisan

Organizations waste an average of 30% of their cloud spend on unused or poorly optimized resources. The good news is that most cost optimization doesn’t require deep technical expertise. Just awareness and consistent actions.

This week in The Cloud Handbook, we are going to cover the best practical tips to reduce your cloud costs immediately.

Let’s get started.

1. Identify and Delete Idle Resources

Unused EC2 instances, forgotten load balancers, and orphaned EBS volumes are silent budget killers. Set up a weekly audit process to identify resources that haven’t been accessed in 30+ days. Most cloud providers offer native tools to track resource utilization. Use them more often. In many cases, developers spin up infrastructure without knowing the business side of it.

2. Right-Size your Instances

This is super important. Maybe you don’t need that m5.2xlarge instance you provisioned two years ago? Instances are charged based on per hour and their sizes. Your application probably doesn’t need it anymore.

Monitor CPU, memory, and network utilization over 2-4 weeks, then downsize accordingly. Even dropping one instance size can save 30-50% on that resource.

This tool is one of my favorites to compare different EC2 instances:

• https://ec2instances.github.io/

3. Turn Off Non-Production Environments

Development and staging environments don’t need to run 24/7. Automate shutdown schedules for nights and weekends. This single change typically saves 65-75% on non-production infrastructure costs.

On AWS, you can easily start and stop the EC2 using the following guide:

Stop and start EC2 instances automatically on a schedule using Quick Setup

4. Use Reserved Instances or Savings Plans

For stable, predictable workloads, commit to 1-3 year terms for discounts of 30-72%. AWS provides a discount up to 72% on reserved instances.

Start conservatively with your baseline usage and scale up your commitments as you gain confidence in your patterns.

5. Leverage Spot Instances for Fault-Tolerant Workloads

AWS Spot Instances are unused EC2 compute capacity that can be purchased at a discount of up to 90% compared to On-Demand prices. Batch processing, CI/CD pipelines, and data analysis jobs are perfect for spot instances up to 90% discounts. Yes, they can be interrupted, but for stateless workloads, the savings are worth the architecture adjustments.

You can visit the pricing page and calculate your pricing. Prices are updated every 5 minutes there.

Spot instances come up with some limitations compared to on-demand instances. Here are the differences:

6. Implement Storage Lifecycle Policies

Read more

Subscribe now

If you want to reach thousands of Cloud, DevOps, Infrastructure Engineers, Cloud Architects and Cloud leaders. Sponsor The Cloud Handbook. Let’s work together.

🧑‍🎓 Self-paced Resources

Here are some of the courses I took in past. These are mostly free and self-paced courses.

• AWS Skill Builder (Official AWS)
  Over 600+ free digital courses by AWS experts covering everything from cloud essentials to advanced topics with labs.
  Link: https://skillbuilder.aws/

• AWS Educate (Official AWS)
  A free learning platform offering cloud skills training and career pathways for students and educators with hands-on labs in storage, compute, networking, databases, and operations.
  Link: https://aws.amazon.com/education/awseducate/

• Free AWS Cloud Practitioner Course by Andrew Brown (YouTube)
  Comprehensive 14-hour beginner course on AWS Cloud concepts, demos, and diagrams, great for learning fundamentals.
  Link:

• AWS Full Course 2025 | AWS Cloud Computing Tutorial for Beginners (YouTube)
  Description: Beginner-friendly full AWS course covering cloud basics, compute, storage, and more.
  Link:

Some other useful Self-paced courses. These are some of the best courses I took earlier in my career. They are such a great value and free of charge.

1. Cloud Essentials - Knowledge Badge Readiness Path

2. Solutions Architect - Knowledge Badge Readiness Path

3. Serverless - Knowledge Badge Readiness Path

4. AWS: AWS Cloud Practitioner Essentials

5. AWS: AWS Cloud Technical Essentials

6. UMGC, USMx: Cloud Computing Security

7. AI: Cloud Computing Foundations

🎤 Best event talks

• Best practices for serverless developers

• Architecting your serverless applications for hyperscale

• Advanced data modeling with Amazon DynamoDB

• Building Distributed Applications with Event Driven Architecture

Or look out for great talks at the AWS Event Channel and GOTO Conference.

👨🏽‍🎓 Courses I have taken for Certifications

• Solutions Architect - Knowledge Badge Readiness Path

• Architecting Solutions on AWS

• AWS Certified Solution Architect Associate

• AWS Certified Solution Architect Professional

• AWS Certified Developer Associate

• AppSync Masterclass

🎙️ Podcasts

• Serverless Chat — Everything Cloud, serverless, news and updates around it.

• AWS FM — AWS, Community, and fun.

• Software Huddle — Software engineering, databases, cloud, and more.

• Ready, Set, Cloud — Serverless, cloud, news, updates, and more.

▶ YouTube Channels

• Tech World with Nana— Mostly talks about DevOps, Cloud, K8s.

• Be a Better Dev — AWS tutorials, best practices, and hands-on projects.

• FooBar Serverless — Serverless queen. Talks mostly about everything AWS serverless.

• Yan Cui TheBurningMonk — Podcasts, interviews, anything aws serverless.

• Tech with Lucy — Cloud career guide, journeys, share her experiences.

🚀 Newsletters

• AWS Fundamentals—All things AWS.

• Serverless Advocate—All things Serverless on AWS

• Cyber Notes — All things security.

• Of by None — All things Cloud, Serverless and community

🏅 Certification Success Stories

Here are some of the stories we published at Towards AWS about builders who successfully cracked various AWS exams.

• How to crack AWS Certified Solutions Architect — Professional exam?

• Path to AWS certified Developer

• How to Ace AWS Data Analytics Specialty Certification Exam Almost For Free

• The Ultimate Guide To Getting Certified

• How I passed AWS Certified Developer Associate Exam?

• How I passed AWS Certified Advanced Networking — Specialty exam..

• Path to AWS Certified Solution Architect — Associate

• Passing the AWS Certified Cloud Practitioner (CLF-C01) and AWS Certified Solutions Architect — Associate (SAA-C02) in 3 months (August 2021)

• Ace AWS Advanced Networking Specialty Exam ANS-C00

Social Threads

This twitter post share best youtube channels to learn AWS and stay up to date.

And this next post share hands-on works to get your hands dirty.

🦹🏻 Cloud Community Heroes

Some of the Cloud community heroes you should be following to stay updated in Cloud field.

Andrew Brown: Andrew Brown is an AWS Hero and makes courses around cloud technology. He also publishes free AWS certification courses on the FreeCodecamp YouTube channel.

Yan Cui—Independent consultant, Yan is a Serverless Hero and advocate in the serverless community. He is the author of multiple books, workshops, and speakers.

Sandro Volpicella—Author of AWS Fundamentals book. He writes, posts, and blogs about AWS technologies regularly on various social platforms.

Alex Debrie—Independent consultant, DynamoDB expert, AWS Serverless Hero, speaker, and podcast host. Talks everything around data, serverless, and AWS.

Tobias Schmidt—I follow him for everything about AWS and beautiful infographics

Lucy Wang — Ex-AWS Solution architect sharing her experiences through youtube videos, and newsletters.

Jeremy Daly — Serverless Hero, blogger, and founder of Ampt.

Jones Zachariah Noel— Advocates for Freshwork, talks about AWS, and writes The Serverless Terminal newsletter.

Lee James Gilmore — Serverless Advocate, Blogger, Speaker, Architect.

Marcia Villalba — Advocate for AWS, makes videos on her YouTube channel about everything about AWS.

…and others few.

Hope you enjoy learning. Keep learning and building.

📬 Get in touch

Liked this issue? Feel free to drop ❤️ and restack with your friends.

If you have any feedbacks or questions 💬, comment below. See you in the next one.

You can find me on Twitter, Linkedin.

Sponsor this Newsletter!

If you want to work with me or want to sponsor the newsletter, please email me at kisan.codes@gmail.com.

You can learn more about the Sponsorships here in details:

See you in the next one! Until then, keep building.