DEV Community: Megha Shivhare

Terraform S3 Native State Locking - Ditch DynamoDB Forever

Megha Shivhare — Tue, 20 Jan 2026 13:17:52 +0000

No more DynamoDB tables for Terraform locking! Terraform 1.9+ introduced S3 native state locking - a built-in mechanism that eliminates the extra AWS resource while keeping your team deployments safe. Here's everything you need to know.

The Problem with DynamoDB Locking

Traditional S3 backend required two AWS resources:

terraform {
  backend "s3" {
    bucket         = "my-state-bucket"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"  # Extra cost + management ❌
    encrypt        = true
  }
}

Issues:

DynamoDB table = always-on cost (~$0.25/month minimum)
Extra IAM permissions to manage
One more resource to create/delete
Lock table drift (table deleted but state remains) ### Enter S3 Native State Locking Terraform 1.9+ (January 2026): use_lockfile = true makes S3 handle locking natively.

terraform {
  backend "s3" {
    bucket       = "my-state-bucket"
    key          = "prod/terraform.tfstate"
    region       = "us-east-1"
    encrypt      = true
    use_lockfile = true  # S3 does it all! ✅
  }
}

How it works:

Terraform creates terraform.tfstate.tflock alongside your state file
S3 manages lock acquisition/release atomically
Optional: Keep DynamoDB for double-locking redundancy
S3 bucket policy needs PutObject for *.tflock files ### Migration: 2 Minutes Flat #### Step 1: Verify compatibility

terraform version  # Must be 1.9.0+

Step 2: Update your backend

# Remove dynamodb_table, add use_lockfile = true

Step 3: Re-init

terraform init -migrate-state

Step 4: Clean up

aws dynamodb delete-table --table-name terraform-locks

Done. Zero downtime, same locking guarantees.

Real-World Test

Scenario: Two terminals, same state file, rapid apply commands.

Before (DynamoDB):

Terminal 1: Acquiring lock via DynamoDB...
Terminal 2: [WAIT] Lock held by Terminal 1

After (S3 Native):

Terminal 1: Acquiring S3 lock...
Terminal 2: [WAIT] Lock held by Terminal 1 (via .tflock)

Identical behavior, one less AWS bill line item.

Gotchas & Requirements

Item	Requirement
Terraform	1.9.0+
S3 Permissions	`PutObject` on `*.tflock` files
Bucket Policy	Allow lock file creation
Existing State	`terraform init -migrate-state`

Bucket policy update:

{
  "Effect": "Allow",
  "Action": ["s3:PutObject"],
  "Resource": "arn:aws:s3:::my-state-bucket/prod/*.tflock"
}

Why This Changes Everything

❌ OLD: S3 state + DynamoDB lock = 2 resources
✅ NEW: S3 state + S3 lock = 1 resource
💰 SAVINGS: ~$3/year per state file
🔧 SIMPLICITY: One less failure point

Production teams: Delete 100+ DynamoDB lock tables across your org.
Solo devs: Zero extra resources for remote state.
CI/CD: Simpler IAM roles.

My Updated Workflow (2026)

# Every project now gets this backend
terraform {
  backend "s3" {
    bucket       = "my-org-terraform-state"
    key          = "env/${terraform.workspace}/terraform.tfstate"
    region       = "us-east-1"
    encrypt      = true
    use_lockfile = true
  }
}

Daily habit:

# Verify locks work
terraform plan  # Should show "Acquiring state lock..."

Try It Now

Create S3 bucket: aws s3 mb s3://my-terraform-state-2026
Update your EC2 .tf with above backend
terraform init
Push your local state: terraform init -migrate-state

Result: Locked, remote, DynamoDB-free Terraform in 5 minutes.

S3 native locking makes Terraform state management finally "set it and forget it." No more lock table drift, no more surprise charges, no more complexity.

Already migrated? What was your experience? Still using DynamoDB? Why? 👇

Terraform Workflow Explained with a Real AWS Example (Beginner Friendly)

Megha Shivhare — Tue, 06 Jan 2026 15:08:17 +0000

Why Terraform

Infrastructure as Code (IaC) tools like Terraform make it possible to define your cloud resources in simple text files and recreate them anytime with a few commands. As a beginner, a great first project is to use Terraform to launch a single EC2 instance on AWS and walk through the full workflow from setup to clean-up.

This post is a hands-on log of that exact journey: one configuration file and five core Terraform commands

Terraform workflow in plain English

Terraform follows a predictable workflow: init → validate → plan → apply → destroy.

terraform init: Prepares the working directory, downloads the AWS provider plugin, and creates a lock file so future runs use the same versions.
terraform validate: Checks that your .tf files are syntactically correct and that the configuration is internally consistent.
terraform plan: Shows what Terraform is going to do, such as which resources will be created, changed, or destroyed, using symbols like + for create.
terraform apply: Runs the plan for real, asks you to confirm with yes, and then creates or updates your infrastructure.
terraform destroy: Destroys the resources you created, again asking you to confirm, which helps avoid surprise cloud bills.

In this example, all these commands are ran from the same working directory where the Terraform configuration files (.tf) live.

Walkthrough: EC2 instance with Terraform

Here is the configuration file used for this simple project: a Terraform settings block, an AWS provider block, and a single EC2 instance resource.

# Terraform Settings Block
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      #version = "~> 5.0" # Optional but recommended in production
    }
  }
}

# Provider Block
provider "aws" {
  profile = "default" # AWS Credentials Profile configured on your local desktop terminal  $HOME/.aws/credentials
  region  = "us-east-1"
}

# Resource Block
resource "aws_instance" "ec2demo" {
  ami           = "ami-068c0051b15cdb816" # Amazon Linux in us-east-1, update as per your region
  instance_type = "t2.micro"
}

The Terraform settings block declares required_providers and tells Terraform to use the official hashicorp/aws provider.
The provider block configures which AWS account and region to use via the profile and region arguments.
The resource block aws_instance describes a single EC2 instance with a specific AMI and instance type (t2.micro).

Step 1: terraform init

From the directory containing this file, running terraform init:

Downloads the AWS provider plugin into a hidden .terraform directory.
Creates a .terraform.lock.hcl file that records the exact provider versions used.

This step is only needed when you first set up the project or change providers.

Step 2: terraform validate

Next, terraform validate checks that the configuration is valid.

If there is a syntax issue (for example, a missing brace or a typo in a block), it will throw an error and point to the problem in the .tf file. A successful validation means Terraform can understand the configuration but hasn’t yet contacted AWS.

Step 3: terraform plan

Running terraform plan shows what Terraform intends to do before touching AWS.

The output includes lines with a + sign, indicating resources that will be created, such as + aws_instance.ec2demo.
At the bottom, Terraform summarizes how many resources will be added, changed, or destroyed.

This is the “dry run” step where you verify that the configuration matches your expectations.

Step 4: terraform apply

terraform apply executes the changes defined in the plan.

Terraform prints the plan again so you can double-check it.
You must type yes to confirm; only then does Terraform call the AWS APIs and create the EC2 instance.

After it completes, you can go to the AWS console, open the EC2 dashboard, and see the instance created from your Terraform configuration.

Step 5: terraform destroy

When you are done experimenting, terraform destroy removes the resources created by Terraform.

Terraform shows a destroy plan, listing resources with a - symbol.
After you type yes, it terminates the EC2 instance and cleans up, helping you avoid unnecessary charges.

HCL basics that clicked

Terraform uses HCL (HashiCorp Configuration Language), which is designed to be both human-readable and machine-friendly.

In the EC2 example:

resource "aws_instance" "ec2demo" {
  ami           = "ami-068c0051b15cdb816"
  instance_type = "t2.micro"
}

resource is the block type, "aws_instance" and "ec2_demo" are block labels.
Inside the block, ami and instance_type are identifiers (argument names), and their right-hand sides are argument values (expressions).

There are two broad types of blocks you will see often:

Top-level blocks such as terraform, provider, and resource.
Nested blocks like provisioner blocks or resource-specific nested blocks such as tags { ... }.

For comments, HCL supports:

// or # for single-line comments.
/* ... */ for multi-line comments.

Thinking in terms of “blocks, arguments, and values” makes HCL much easier to read and write.

What I’d do next

Once this basic workflow feels comfortable, natural next steps could be:

Add tags to the EC2 instance using a tags block to practice nested blocks.
Introduce variables (for AMI ID, instance type, or region) to avoid hardcoding values and make the configuration reusable.
Create additional resources, such as a security group and attach it to the instance, to see how Terraform manages relationships.
Later, explore remote state (for example, storing state in an S3 bucket) when you are ready to collaborate or work with multiple environments.

This single EC2 example is already enough to build confidence with the Terraform workflow, and it gives you a clean foundation for more advanced IaC experiments.

Trigger Lambda from SQS in Minutes: No-Fluff Guide

Megha Shivhare — Wed, 09 Apr 2025 13:45:48 +0000

A step-by-step guide on how to trigger lambda using SQS

In this blog, we'll walk through how to set up an AWS Lambda function that processes messages from an Amazon SQS (Simple Queue Service) queue. This is a common pattern in serverless applications, useful for decoupling and buffering tasks.

1. Create a Lambda Function

Go to AWS Lambda → Click on Create function
Choose the following settings:
- Runtime: Python, Node.js, etc. (your choice)
- Architecture: Arm64 (cheaper and efficient)
- Permissions: Select “Create a new role from AWS policy templates” Attach the Amazon SQS poller permissions template to allow the Lambda function to access SQS.

Click Create function.

2. Add Your Lambda Code

Remove the default sample code.
Start by printing the event to understand its structure:

def lambda_handler(event, context):
    print(event)

This helps you inspect the incoming SQS message structure. A typical event will include a list of Records, each containing a body field, which holds the actual message content.

Update your code to extract and process messages:

def lambda_handler(event, context):
    for record in event['Records']:
        message_body = record['body']
        print("Message Received:", message_body)

Click Deploy to save changes.

3. Test the Lambda Function

Click on Test → Create a new test event.
Choose the SQS Event Template.
Modify the body field with your sample message.

Click Invoke and check the logs/output.

4. Create an SQS Queue

Go to Amazon SQS → Click Create Queue
Keep the default settings (you can fine-tune later if needed)
After creation, go back to your Lambda function.

5. Wire SQS to Lambda

Inside your Lambda function → Choose Add trigger
Select SQS → Choose the queue you just created
Save the trigger

Now your Lambda function is ready to process real messages sent to this queue.

6. Test the End-to-End Flow

Go to SQS → Choose your queue → Click on Send and receive messages
Send a test message

Your Lambda function should automatically trigger, process the message, and log the output.

To monitor:

Go to Lambda → Monitor tab → View logs in CloudWatch

Conclusion

You’ve successfully integrated AWS SQS with Lambda! This setup is a foundational pattern for building decoupled, scalable, and resilient serverless applications. You can now extend it by adding error handling, DLQs (dead letter queues), batching, and more.

Why Every AWS User Should Understand RFCs in Managed Services

Megha Shivhare — Tue, 18 Feb 2025 05:41:34 +0000

Introduction
Amazon Web Services (AWS) Managed Services (AMS) is an enterprise service that provides ongoing management of your AWS infrastructure. AWS infrastructure management includes procedures that cover the lifecycle of deploying, supervising, improving, and maintaining technology and resources in the Amazon Web Services cloud environment. AWS Managed Services simplifies deployment, migration, and management using automation and machine learning, which accelerates cloud adoption.

In the context of AWS, RFC stands for Request for Change. An RFC is how you make a change in your AMS-managed environment or ask AMS to make a change on your behalf. Understanding RFCs is essential for AWS users, especially in managed environments, because it is the way to implement changes in your AWS-managed environment.

What is RFC in AWS Managed Services?
A Request for Change (RFC) is how you make a change in your AMS-managed environment, or ask AMS to make a change on your behalf. RFCs play a critical role in IT service management by formalizing the process of requesting, reviewing, and implementing changes to IT systems. To create an RFC, you select from AMS change types, choose RFC parameters (such as schedule), and then submit the request using either the AMS console or the API commands CreateRfc and SubmitRfc.

AWS Managed Services (AMS) uses RFCs to handle infrastructure changes by coordinating all actions on resources. Changes must originate with a change request (an RFC), and can be manual or scripted. AWS MS makes sure that changes are applied to individual stacks on an orderly, non-overlapping basis and also holds all incoming manual requests until they have been approved.

Different types of RFCs:

Standard RFCs are routine changes that are pre-approved and well-documented.
Emergency RFCs are implemented to address critical issues or outages that require immediate action.

Why is RFC Important in AWS Managed Environments?
RFCs are important because they ensure controlled and auditable infrastructure changes. It helps maintain compliance with industry standards like ISO, SOC, and HIPAA. A well-structured RFC process reduces risk and prevents unintended downtime or service disruptions. Also, it enhances collaboration and accountability in large organizations.

How AWS Implements RFCs?
To submit an RFC in AWS Managed Services, you configure the request and the parameters for the request. An RFC contains two specifications: one for the RFC itself and one for the change type (CT) parameters. At the command line, you can use an Inline RFC command or a standard CreateRfc template in JSON format that you fill out and submit along with the CT JSON schema file that you create (based on the CT parameters). You can create and submit an RFC with the CreateRfc API, aws amscm create-rfc CLI, or using the AMS console Create RFC pages.

Approval workflows involve AWS MS coordinating all actions on resources[6]. AWS MS makes sure that changes are applied to individual stacks on an orderly, non-overlapping basis and also holds all incoming manual requests until they have been approved.

AWS implements automation of RFCs through AWS services like Lambda, SNS, and CloudFormation.

Common Use Cases of RFC in AWS Managed Services

Patching EC2 instances and managed databases.
Scaling infrastructure (adding/removing instances, modifying configurations).
Enabling new security policies or IAM role changes.
Upgrading Kubernetes clusters in EKS.

Best Practices for Managing RFCs in AWS

Submitting detailed RFCs with proper justifications.
Using automation tools to streamline RFC approval processes.
Monitoring RFC execution and rollback strategies in case of failures.
Keeping a record of past RFCs for audits and learning.

Conclusion
RFCs are crucial in AWS Managed Services because they ensure that changes to your infrastructure are controlled, auditable, and aligned with best practices[6]. By following best practices for managing RFCs, organizations can ensure smooth and secure cloud operations. Integrating a well-defined RFC process in your AWS workflows is essential to maintaining a stable, secure, and compliant cloud environment.

Infrastructure as Code with AWS CloudFormation

Megha Shivhare — Thu, 13 Feb 2025 17:12:36 +0000

AWS CloudFormation is a powerful service that allows you to define and provision AWS infrastructure as code. By using CloudFormation templates, you can automate the creation and management of AWS resources, making it easier to deploy applications consistently and efficiently. This guide provides an overview of AWS CloudFormation templates (CFT), focusing on the two primary formats: YAML and JSON.

What is an AWS CloudFormation Template?

An AWS CloudFormation template is a JSON or YAML formatted text file that describes the resources needed to run your application. These templates serve as blueprints for creating and managing stacks, which are collections of AWS resources that you can manage as a single unit. Each template consists of several sections, with the Resources section being mandatory. This section defines the specific AWS resources and their configurations.

Key Sections of a CloudFormation Template

AWSTemplateFormatVersion: Specifies the version of the template format.
Description: A brief description of what the template does.
Metadata: Additional information about the template.
Parameters: Values that can be passed to the template at runtime.
Mappings: Static variables that can be referenced in the template.
Conditions: Conditions that control resource creation based on parameter values.
Resources: The only required section, defining the AWS resources to create.
Outputs: Values returned when the stack is created.

Here’s an example of a simple YAML template defining an S3 bucket:

AWSTemplateFormatVersion: '2010-09-09'
Description: A simple S3 bucket
Resources:
  MyS3Bucket:
    Type: 'AWS::S3::Bucket'
    Properties:
      BucketName: my-example-bucket

Choosing Between YAML and JSON

Both YAML and JSON are supported formats for writing CloudFormation templates, each with its advantages:

YAML:
- More human-readable due to its indentation-based structure.
- Less verbose and easier to write, especially for complex configurations.
JSON:
- Strictly structured, which can make it easier for machines to parse.
- May become cumbersome for humans when dealing with deeply nested structures.

The choice between YAML and JSON often depends on personal preference or team standards.

Creating and Validating Templates

To create a CloudFormation template, you can use various methods:

Text Editor: Write directly in YAML or JSON format.
AWS CloudFormation Designer: A visual tool for designing templates.
Infrastructure as Code (IaC) Generators: Tools that generate templates from existing resources.

Once you have created your template, it's crucial to validate it before deployment. You can use the AWS Management Console or command-line tools like aws cloudformation validate-template to check for syntax errors.

Deploying CloudFormation Templates

Deploying a CloudFormation template involves creating a stack based on the defined resources. There are several methods to deploy:

AWS Management Console:
- Navigate to the CloudFormation service.
- Select "Create stack" and upload your template file.
AWS CLI:
- Use commands like aws cloudformation create-stack to deploy via scripts or automation tools.
CI/CD Integration:
- Integrate with tools like AWS CodePipeline for automated deployments based on source control changes.

Best Practices for Writing CloudFormation Templates

Use Parameters and Mappings: Make your templates reusable by allowing input parameters and defining mappings for different environments.
Validate Regularly: Use tools like cfn-lint for best practice checks and validation against resource provider schemas.
Organize Resources Logically: Group related resources together in your templates for better readability and maintenance.
Document Your Templates: Include descriptions and comments within your templates to clarify their purpose and usage.

Conclusion

AWS CloudFormation templates are essential tools for managing infrastructure as code in AWS environments. By utilizing either YAML or JSON formats, developers can automate resource provisioning, ensuring consistency and efficiency across deployments. Following best practices in template design will enhance maintainability and usability, making it easier to manage complex infrastructures over time.

By mastering AWS CloudFormation templates, you can streamline your cloud operations and focus more on developing applications rather than managing infrastructure manually.

Mastering Spot Instances & Spot Fleets – Save Money on AWS EC2

Megha Shivhare — Tue, 11 Feb 2025 06:21:35 +0000

Introduction

Amazon Elastic Compute Cloud (EC2) provides computing capacity in the AWS cloud, allowing you to launch virtual servers with a variety of operating systems. EC2 offers different pricing models, including On-Demand, Savings Plans, Reserved Instances, Spot Instances, and Dedicated Hosts, each designed to cater to different needs and usage patterns. Spot Instances can provide significant cost savings. Spot Instances are available at a discount of up to 90% off compared to On-Demand pricing.

This blog post will explore how Spot Instances and Spot Fleets work, their benefits, and some best practices for leveraging them effectively.

EC2 Instance Pricing Models Comparison

Pricing Model	Description	Use Cases	Cost Optimization
On-Demand	Pay for compute capacity by the hour or second, only for what you use. No long-term commitments or upfront payments.	Short-term workloads, unpredictable spikes in demand, software development, and testing.	Right-size instances, use auto-scaling.
Savings Plans	Commit to a consistent amount of compute usage (measured in $/hour) for 1 or 3 years. Lower prices compared to On-Demand.	Steady-state usage, predictable workloads.	Choose the right Savings Plan type (Compute Savings Plan or EC2 Instance Savings Plan) for your workload.
Reserved Instances	Provide a capacity reservation and offer a significant discount on the hourly charge for EC2 instances. Contract terms of 1 or 3 years.	Applications with steady-state or predictable usage, require capacity reservations.	Evaluate utilization, consider convertible RIs for flexibility.
Spot Instances	Request spare EC2 capacity, paying up to 90% less than On-Demand prices. Instances can be interrupted with a two-minute warning.	Applications with flexible start and end times, urgent spikes in demand. Batch processing, CI/CD, data processing.	Use Spot Fleets for diversification, implement checkpointing for fault tolerance.
Dedicated Hosts	Physical EC2 servers dedicated for your use. Allows you to use your existing server-bound software licenses.	Regulatory requirements, licensing constraints.	Optimize instance utilization, consider AWS License Manager.

What Are AWS Spot Instances?

Spot Instances allow you to request spare EC2 capacity, and pay significantly less (up to 90% off) the original on-demand price. Because they can be interrupted on short notice, spot instances are typically used for applications working at flexible start and end schedules, or to accommodate urgent spikes in demand for compute resources. The pricing of Spot Instances varies based on supply and demand.
Spot Instance prices are set by Amazon EC2 and adjust gradually based on long-term trends in supply and demand for Spot Instance capacity. Unlike On-Demand Instances, where you pay a fixed price per hour or second, Spot Instances involve a dynamic pricing mechanism.

What Are Spot Fleets?

Spot Fleets manage multiple Spot Instances dynamically. They offer auto-replacement, cost efficiency, and the ability to use mixed instance types. Spot Fleets are well-suited for batch processing, containerized workloads, and machine learning training. A Spot Fleet request includes the number of instances required, type of instances, the target capacity, and maximum price.

You decide on a maximum price you are willing to pay. Once the price set by AWS exceeds this threshold, Spot Fleets are terminated, typically with a two-minute grace period.

When & Where to Use Spot Instances?

Spot Instances are best suited for:

Stateless applications
CI/CD pipelines
Data processing jobs
Auto-scaling groups

However, avoid using Spot Instances for critical workloads that require guaranteed uptime.

How to Request & Manage Spot Instances?

To use Spot Instances, you must decide on your maximum spot price. The instance will be provisioned as long as the spot price is below your maximum bid. You can use Spot Fleet requests and EC2 Auto Scaling to manage your Spot Instances. It's crucial to set a maximum bid price and have a strategy for handling instance interruptions.

Handling Spot Interruptions Gracefully

AWS provides a two-minute notification before terminating a Spot Instance. You can use Instance Termination Notices and EC2 Hibernate to manage these interruptions. Strategies for handling interruptions include checkpointing, using Auto Scaling to replace interrupted instances, and falling back to On-Demand Instances if necessary.

Cost Optimization Tips for Spot Instances

Combine On-Demand and Spot Instances in Auto Scaling groups.
Leverage the Spot Instance Advisor for better pricing decisions.

Spot Instance Allocation Strategies

When using Spot Instances, you can employ different allocation strategies to optimize for cost and availability:

Price-Capacity-Optimized: This strategy makes Spot allocation decisions based on both capacity availability and Spot prices.
Lowest Price: While requesting Spot Instances, it's recommended to use the default maximum price, which is the On-Demand price.
Diversified Instances: Spot Fleets let you select instances from different spot pools. EC2 tries to maintain the target capacity, adding spot instances if available, based on the request details.

Conclusion

Spot Instances and Spot Fleets provide a powerful way to reduce costs on AWS EC2. By understanding how they work and implementing best practices for managing them, you can take full advantage of the cost savings they offer.

Have you used Spot Instances before? Share your experience in the comments!

How I Passed the AWS Practitioner Exam: Study Tips + Resources

Megha Shivhare — Fri, 24 Jan 2025 15:38:26 +0000

If you're just starting your AWS journey, the AWS Certified Cloud Practitioner exam is the perfect foundational step. It’s designed to test your understanding of core AWS services, global infrastructure, and basic cloud concepts. Here’s how I prepared for and successfully passed the exam.

Understand the Basics of AWS Services

AWS offers over 200 services, but don’t worry—the exam doesn’t expect you to know them all! Instead, following are the AWS services I was tested on the most, focus on these foundational services and concepts:

IAM (Identity and Access Management): Learn about users, groups, roles, MFA, and CLI setup.
EC2: Understand instance types, security groups (and common ports like SSH and HTTP), instance connect, and purchasing options (spot, reserved, etc.).
EC2 Instance Storage: Get familiar with EBS, snapshots, AMIs, and an overview of FSx.
Load Balancing and Scaling: Study the concepts of ELB (Elastic Load Balancer) and ASG (Auto Scaling Group) to understand scalability and elasticity.
S3 (Simple Storage Service): Cover bucket policies, versioning, replication, storage classes, encryption, and tools like Snowball Edge and Storage Gateway.
Databases and Analytics: Focus on RDS (Relational Database Service), DynamoDB, Aurora, ElasticCache, and an overview of services like Redshift and Glue.
Compute Services: Explore ECS, Fargate, Lambda (serverless), Lightsail, and API Gateway.
Deployment Tools: Get a basic understanding of CloudFormation, CDK, Beanstalk, CodeDeploy, and related services.
Global Infrastructure: Learn about Route 53, CloudFront, Global Accelerator, and Local Zones.
Monitoring: Focus on CloudWatch, EventBridge, CloudTrail, and the AWS Health Dashboard.
Networking: Understand VPC, subnets, security groups, NAT gateways, Direct Connect, and VPN options.
Security & Compliance: Cover DDoS protection, encryption, GuardDuty, Inspector, and IAM Access Analyzer.
Account Management: Study billing tools, AWS Organizations, cost allocation tags, and budgets.
Machine Learning: Gain an overview of services like Rekognition, Sagemaker, and Textract.
Architected Framework: Familiarize yourself with the six pillars of the AWS Well-Architected Framework and tools like AWS IQ.

Study the Shared Responsibility Model

AWS's shared responsibility model what AWS manages (e.g., infrastructure) versus what you manage (e.g., securing your data). You can expect(most probabl) at least one question about this in the exam.

Additional Services to Explore

While these might not be the exam’s main focus, having a basic understanding of the following services can be helpful:

Workspaces
AppStream 2.0
IoT Core
Elastic Transcoder
AppSync and Amplify
Device Farm
DataSync
Step Functions
Fault Injection Simulator
AWS Pinpoint
Elastic Disaster Recovery

My Study Tips

Focus on High-Yield Topics: Spend most of your time on core services like IAM, EC2, S3, and VPC.
Practice Questions: Take as many practice tests as possible to familiarize yourself with the question style.
Use AWS Free Tier: Experimenting hands-on with AWS services helped me solidify my understanding.
Leverage AWS Documentation and Training: The AWS website has free resources and FAQs that are incredibly useful.
Create a Study Schedule: Set aside consistent study hours to stay on track.

Resources to Help You Prepare

AWS Free Tier: Practice hands-on with core services.
Practice Exams: Check out these free sample questions and practice tests to test your knowledge:
- AWS Official Sample Questions [Free]
- Free Practice Exams - Nirav Kanani
Notes & online courses:
- Udemy - Stephane Maarek [Paid]
- AWS Cloud Practitioner course - Hitesh Choudhary [Free]
- Study Guide - Nirav Kanani [Free]

Be Aware of Exam Details

The AWS Certified Cloud Practitioner exam consists of 65 questions, but only 50 are scored. The remaining 15 are experimental questions that won’t affect your score—however, you won’t know which ones they are. To pass, you’ll need a score of at least 700 out of 1,000 (around 70%).
Review the official AWS study guide properly before appearing for the exam.

With a solid understanding of these core concepts, some dedicated preparation, and the right resources, passing the AWS Certified Cloud Practitioner exam is completely achievable. Good luck!

Note : I appeared for the exam on Dec, 2024. Please look out for any changes in the exam structure/schedule or details accordingly.

Essential Linux Commands for DevOps Engineers

Megha Shivhare — Sun, 19 Jan 2025 12:05:19 +0000

As a DevOps engineer, mastering Linux commands is fundamental for managing infrastructure, automating tasks, and ensuring seamless deployments. This blog highlights critical Linux command categories that every DevOps professional should know.

1. Process Management

Process management is vital for controlling and monitoring applications running on Linux systems. Here are essential commands:

Key Commands and Their Usage:

List processes:

ps aux        # Shows all running processes
ps -ef        # Alternative format for process listing
ps -u username # Processes for a specific user

Process monitoring:

top           # Interactive process viewer
htop          # Enhanced version with color coding and mouse support

Process control:

kill PID      # Send SIGTERM to terminate a process
kill -9 PID   # Forcefully terminate a process
killall name  # Kill all processes by name

Service management:

systemctl start service   # Start a service
systemctl stop service    # Stop a service
systemctl restart service # Restart a service

Process priority management:

nice -n 10 command        # Start command with lower priority
renice -n 10 -p PID       # Adjust priority of a running process

2. File System Management

Linux filesystems are organized in a tree structure. Managing files and directories is integral to system administration.

Key Commands and Their Usage:

File permissions:

chmod 755 file            # rwx for owner, rx for others
chown user:group file     # Change ownership

File searching:

find / -type f -name "*.log"   # Find all log files
find / -mtime -7               # Files modified in the last 7 days

Disk usage:

du -sh *                     # Size of directory contents
df -h                        # Filesystem usage

3. Network Management

Network configuration and troubleshooting are key DevOps skills.

Key Commands and Their Usage:

Network connectivity:

ip addr      # Show IP addresses
ping -c 4 host # Test connectivity with 4 packets

Port monitoring:

netstat -tulpn     # Show listening ports and processes
ss -tunlp          # Modern alternative to netstat

Network debugging:

tcpdump -i eth0    # Capture packets on a network interface
nmap localhost     # Scan open ports

4. System Monitoring

Monitoring system performance ensures reliable operations.

Key Commands and Their Usage:

Resource monitoring:

free -m            # Display memory usage in MB
vmstat 1           # Virtual memory stats updated every second

Performance analysis:

perf top           # CPU performance analysis
strace command     # Trace system calls

5. Log Management

Logs are essential for debugging and auditing system activities.

Key Commands and Their Usage:

System logs:

journalctl -f                # Follow system logs
journalctl -u service        # View service-specific logs
tail -f /var/log/syslog      # Follow the system log

Log analysis:

grep -r "error" /var/log/    # Search for errors in logs
awk '/pattern/ {print $1,$2}' logfile # Extract specific fields

6. Package Management

Managing software packages efficiently is crucial for system updates and deployments.

Key Commands and Their Usage:

For RHEL/CentOS:

yum update -y             # Update all packages
yum install package       # Install a specific package

For Ubuntu/Debian:

apt update && apt upgrade # Update system
apt install package       # Install a package

7. Security Management

Securing systems involves managing user access, monitoring, and hardening configurations.

Key Commands and Their Usage:

User management:

useradd -m username    # Create a user with a home directory
passwd username        # Set a password for the user

Security monitoring:

last                   # Show last logins
fail2ban-client status # Display banned IPs

Conclusion

Mastering these Linux commands will enhance your efficiency as a DevOps engineer. They are essential for automation, troubleshooting, and maintaining secure, high-performing systems.

Understanding Elastic IPs: Use Cases, Best Practices, and Limitations

Megha Shivhare — Sun, 12 Jan 2025 07:39:35 +0000

What is an Elastic IP?

An Elastic IP (EIP) is a static, public IPv4 address designed specifically for dynamic cloud computing. Unlike regular public IP addresses, which can change when an instance stops and starts, an Elastic IP remains static. Key characteristics include:

Account Association: EIPs are associated with your AWS account rather than being tied to a specific instance by default.
Remapping Capability: You can remap an EIP from one instance to another within the same AWS region.
Persistence: The EIP remains allocated to your account until explicitly released.

Elastic IPs provide flexibility and reliability for applications that require a fixed public IP address, making them ideal for certain high-availability and disaster recovery scenarios.

Use Cases

1. High Availability

Elastic IPs are crucial for applications that demand high availability. They allow you to quickly remap the IP address to a backup instance if the primary one fails.

Example:

Your primary EC2 instance fails.
Remap the EIP to a backup EC2 instance in the same region.
Traffic seamlessly resumes without requiring DNS changes.

2. Static IP for Critical Services

EIPs are ideal for hosting services that require a fixed IP, such as:

Setting up DNS records.
Scenarios requiring IP whitelisting for access control.
Integration with external services that rely on a constant IP address.

3. Disaster Recovery

Elastic IPs are an integral part of failover strategies. They provide a DNS-independent recovery option, ensuring minimal downtime.

Example:

In a disaster recovery setup, traffic can be redirected to a secondary environment by remapping the EIP.

Best Practices

1. Cost Management

Elastic IPs are cost-effective when used appropriately, but AWS charges apply under specific circumstances:

Free:
- When associated with a running instance.
- If only one EIP is allocated per instance.
Charged:
- When the EIP is not associated with any instance.
- If associated with a stopped instance.
- When multiple EIPs are allocated to the same instance.

2. Resource Management

Efficient resource management ensures you make the most of EIPs:

Do:

Use DNS names instead of EIPs when possible.
Release unused EIPs to avoid unnecessary charges.
Tag EIPs for better tracking and management.
Use EIPs only when absolutely necessary.

Don’t:

Allocate EIPs for temporary use cases.
Keep unassociated EIPs idle.
Use EIPs for internal communication; private IPs are better suited for this.

3. High Availability Setup

Follow this recommended pattern to ensure high availability:

Create a primary EC2 instance.
Create a backup EC2 instance.
Allocate an Elastic IP.
Associate the EIP with the primary instance.
Set up health monitoring.
Use a script or automation to move the EIP to the backup instance if the primary fails.

4. Security Considerations

Secure your Elastic IPs to prevent misuse:

Use security groups to control access to resources associated with EIPs.
Monitor EIP usage and access patterns.
Document which services and applications use each EIP.
Implement strict IAM policies for EIP allocation and management.

Limits and Quotas

Be aware of the following constraints when using Elastic IPs:

Default Limit: 5 Elastic IPs per region (can request an increase).
Region-Specific: EIPs cannot be moved between regions.
Mapping Constraints: Each EIP maps to one primary private IP per instance.
Connectivity Interruption: Remapping an EIP between instances may cause brief connectivity disruptions.

Consider Modern Alternatives

While Elastic IPs are useful, they might not always align with modern cloud architecture. For scalable and resilient systems, consider using:

DNS

Route 53 provides advanced routing options (geolocation, failover, weighted routing) and integrates seamlessly with Auto Scaling.

Elastic Load Balancers (ELBs)

Distribute traffic across multiple targets, support auto-scaling, and provide built-in health checks.

These alternatives reduce dependency on static IPs, improve scalability, and align with modern architectural practices.

Conclusion

Elastic IPs remain a powerful tool in AWS for applications requiring a fixed IP address, high availability, or disaster recovery capabilities. However, they should be used judiciously to manage costs and resources effectively. For most modern use cases, leveraging DNS and Elastic Load Balancers offers greater flexibility, scalability, and alignment with cloud-native best practices.

AWS Global Infrastructure Explained for Newcomers

Megha Shivhare — Sun, 15 Dec 2024 13:25:34 +0000

AWS's global infrastructure serves as the backbone of its cloud services, providing a robust and reliable platform for businesses around the world. Understanding its key components is essential for beginners looking to leverage AWS effectively. This blog provides you a breakdown of the primary elements that make up this extensive network.

Key Components of AWS Global Infrastructure

Regions

Regions are large geographic areas that host multiple Availability Zones (AZs). Each region operates independently, ensuring that services remain unaffected by issues in other regions. Currently, AWS boasts over 34 regions worldwide, including notable locations like:

US East (N. Virginia)
EU (Ireland)
Asia Pacific (Tokyo)

This geographic distribution allows AWS to provide services closer to users, enhancing performance and reducing latency.

Availability Zones (AZs)

Each region contains multiple AZs, which can be thought of as individual data centers within that region. These AZs are interconnected through high-speed, low-latency networks, enabling seamless data transfer and redundancy. For instance, the US East (N. Virginia) region comprises 6 AZs. If one AZ experiences a failure, others can take over, ensuring high availability and fault tolerance for applications. The minimum number of AZs in a region can be 3, while the maximum limit is 6.

Edge Locations

Edge locations serve as mini data centers strategically placed around the globe to cache content closer to end users. They are primarily part of Amazon CloudFront, AWS's content delivery network (CDN). With over 200 edge locations, these facilities significantly improve the speed of content delivery for applications like streaming services or websites by reducing latency.

Local Zones

Local Zones are smaller data centers located near major metropolitan areas. They are designed for applications requiring ultra-low latency, such as gaming or media streaming. By placing resources closer to end users, Local Zones enhance performance and responsiveness.

Real-World Analogy

To better understand these components, consider this analogy:

Regions are like major distribution centers.
Availability Zones function as warehouses within those centers.
Edge Locations act as local delivery stations.
Local Zones serve as neighborhood pickup points.

Best Practices for Utilizing AWS Infrastructure

To optimize performance and reliability when using AWS services, consider the following best practices:

Choose Regions Closest to Users: This minimizes latency and improves response times.
Utilize Multiple Availability Zones: This enhances fault tolerance and ensures high availability.
Leverage Edge Locations: Use these for faster content delivery to end users.

Benefits of AWS Global Infrastructure

The design of AWS’s global infrastructure ensures several key advantages:

High Availability: Services remain operational even during outages.
Fault Tolerance: Redundant systems provide backup in case of failures.
Low Latency: Quick response times enhance user experience.
Global Reach: Services can be deployed worldwide, catering to a diverse customer base.

Conclusion

AWS's global infrastructure is a sophisticated network designed to deliver cloud services efficiently and reliably. By understanding its components—regions, availability zones, edge locations, and local zones—newcomers can better navigate the AWS ecosystem and leverage its capabilities for their applications.

Why Basics Matter: Building a Strong Foundation in AWS and DevOps

Megha Shivhare — Fri, 06 Dec 2024 06:58:02 +0000

As technology continues to advance, the fields of cloud computing and DevOps are becoming increasingly vital. For beginners stepping into Amazon Web Services (AWS) and DevOps, establishing a strong foundational knowledge is essential for long-term success. This blog aims to inspire newcomers to prioritize these basics, ensuring they have the tools needed to thrive in their careers.

The Importance of Foundational Knowledge

1. Grasping Core Concepts

Before diving into advanced tools and methodologies, it's crucial to understand the fundamental concepts of AWS and DevOps. AWS offers a plethora of services that can be overwhelming at first. By familiarizing yourself with key terms like Infrastructure as Code (IaC), Continuous Integration (CI), and Continuous Delivery (CD), you lay the groundwork for more complex topics.

2. Developing Problem-Solving Skills

A solid foundation enables beginners to troubleshoot issues more effectively. When challenges arise, understanding the underlying principles allows for faster identification of problems and implementation of solutions. For instance, knowing how CI/CD pipelines work can help you quickly pinpoint where a deployment might have failed.

3. Building Confidence

Starting with a strong grasp of the basics instills confidence in newcomers. This confidence is crucial when transitioning to more advanced topics or collaborating with experienced teams. As you become comfortable with foundational concepts, you're more likely to engage actively in discussions and contribute meaningfully to projects.

Key Areas to Focus On

1. Cloud Computing Fundamentals

Understanding cloud computing is paramount for anyone working with AWS. Key areas include:

1. IaaS, PaaS, and SaaS: Recognizing the differences between these service models helps in selecting the right solutions for specific needs.
2. AWS Services: Familiarity with core services such as EC2 (Elastic Compute Cloud) and RDS (Relational Database Service) is essential for effective application deployment.

2. DevOps Principles

Before jumping straight into tools like Jenkins, it’s vital to first understand what DevOps actually means. First try to understand "What is DevOps?" and how it fit's into the software lifecycle journey. I personally recommend this code champ's video that provides an excellent overview that can help solidify your understanding.

The roadmap for mastering DevOps should look something like this:

1. Foundational Skills: Start with Linux, shell scripting, Python, Git, and GitHub.
2. Core IT Skills: Learn about the OSI model, DNS, DHCP, scaling, SSL/TLS, proxies, load balancers, etc.
3. Cloud Services: Gain expertise in AWS or other cloud platforms like Azure or GCP.
4. DevOps Tools: Once you have the basics down, explore tools like Jenkins, Docker, Kubernetes (K8s), Grafana, and Ansible.
5. Practical Projects: Finally, apply your knowledge through projects such as setting up a three-tier architecture or configuring Kubernetes.

Practical Steps for Beginners

1. Leverage Free Resources

AWS offers a Free Tier that allows users to experiment with various services without incurring costs. This is an excellent opportunity for beginners to learn hands-on without financial pressure.

2. Utilize Documentation and Tutorials

AWS provides extensive documentation that serves as a valuable resource for learning about its services. Engaging with tutorials can help reinforce theoretical knowledge through practical application.

3. Start Small

Begin with simple projects before tackling more complex tasks. This approach helps build confidence while gradually expanding your skill set.

Conclusion

In conclusion, prioritizing foundational knowledge in AWS and DevOps is vital for anyone looking to thrive in these fields. By understanding core concepts, enhancing problem-solving skills, and building confidence through practical experience, beginners can establish a strong foothold in their careers. As technology continues to evolve, those who invest time in mastering the basics will be better equipped to adapt and succeed in the future.

Embrace the journey of learning; after all, every skyscraper stands tall because of its solid foundation!

AWS CloudFront vs AWS Global Accelerator: Understanding Their Differences

Megha Shivhare — Sat, 30 Nov 2024 14:37:32 +0000

AWS offers a range of services to optimize application performance, availability, and delivery. Two such services are AWS CloudFront and AWS Global Accelerator. While both of them use AWS's global network infrastructure, they cater to different use cases and application needs.
This blog post discusses the similarities and differences among these two, hence helping you choose the perfect fit for you!

Basic Overview

AWS CloudFront:

A Content Delivery Network (CDN) designed to deliver content, videos, APIs, and applications with low latency through a network of edge locations.

AWS Global Accelerator:

A networking service aimed at improving application availability and performance using AWS's global network and static IP addresses.

Similarities Between CloudFront and Global Accelerator

Both services share several key characteristics:

Operate on AWS’s global network infrastructure.
Enhance application performance and availability.
Provide worldwide edge locations for optimal user experience.
Include DDoS protection through AWS Shield.
Support health checks for endpoint monitoring.
Integrate with Application Load Balancers.
Work with both IPv4 and IPv6.

Differences

The table above gives an overview on differences between both the services. Now let's take a deeper dive into the key factors that might effect the selection of service.

Key Use Cases

When to Use AWS CloudFront

Delivering static content like images, videos, and HTML files.
Accelerating dynamic content delivery for web applications.
Streaming video and audio content globally.
Distributing software updates.
Hosting static websites with edge security features.
Accelerating APIs for faster responses.
Implementing content personalization at the edge.

When to Use AWS Global Accelerator

Supporting gaming applications (UDP traffic).
Managing IoT devices with protocols like MQTT.
Facilitating Voice over IP (VoIP) communication.
Delivering live media streaming.
Applications requiring static IPs for consistent routing.
Ensuring multi-region failover for high availability.
Powering global applications with predictable performance.
Supporting both TCP and UDP workloads.

Pricing Comparison

Pricing is a crucial consideration when choosing between CloudFront and Global Accelerator. Here's a high-level comparison of their pricing models:

AWS CloudFront Pricing

Data Transfer Out: Charged based on the amount of data delivered from edge locations to users. Costs vary by region.
Requests: Charged based on the number of HTTP/HTTPS requests made.
Additional Features: Services like real-time logs, origin shield, or custom SSL certificates may incur extra costs.
Free Tier: AWS offers 1 TB of data transfer out and 10 million HTTP/HTTPS requests for free in the first year.

AWS Global Accelerator Pricing

Accelerator Hours: Billed per hour for each active accelerator.
Data Transfer: Charged based on the volume of data transferred through the accelerator, with costs varying by source and destination regions.
Static IPs: No additional charge for the static IPs provided.
No Free Tier: Unlike CloudFront, there is no free tier for Global Accelerator.

For detailed and up-to-date pricing, visit the AWS CloudFront Pricing and AWS Global Accelerator Pricing pages.

Additional Features

CloudFront

Origin Shield to reduce origin server load.
Field-level encryption for secure data transfer.
Real-time logs for monitoring and analytics.
Support for custom SSL certificates.
Cache behaviors to optimize content delivery.
Query string parameter handling for dynamic content caching.

Global Accelerator

Client affinity for maintaining consistent sessions.
Network zone isolation for fault tolerance.
Traffic dials to control regional traffic distribution.
Bring Your Own IP (BYOIP) for legacy systems.
Custom routing for advanced traffic patterns.
Continuous endpoint monitoring for availability.
Instant regional failover for disaster recovery.

When to Choose Which Service

Choose AWS CloudFront When You:

Need content caching to reduce server load.
Require edge computing capabilities for low-latency operations.
Want to integrate with AWS Web Application Firewall (WAF).
Handle HTTP/HTTPS workloads.
Need URL-based routing for content distribution.

Choose AWS Global Accelerator When You:

Need static IP addresses for consistent routing.
Operate applications with TCP/UDP workloads.
Require fast and reliable regional failover.
Need client affinity for session persistence.
Handle non-HTTP/HTTPS applications.

Final Thoughts

Choosing between AWS CloudFront and AWS Global Accelerator ultimately depends on your application's requirements.

For Content Delivery: If your primary goal is to deliver content such as static files, videos, or API responses to users worldwide with low latency, AWS CloudFront is the ideal choice. It excels in caching, edge computing, and optimizing HTTP/HTTPS workloads while offering robust security features like WAF and Origin Shield.
For Networking Performance: If your application requires static IPs, predictable routing, or needs to handle protocols like TCP and UDP (common in gaming, IoT, and live streaming), AWS Global Accelerator is the better option. Its ability to provide instant failover and consistent performance across regions makes it a strong candidate for applications needing high availability and reliability.

Using Both: In many cases, these services can complement each other. For example, you could use CloudFront for content delivery along with Global Accelerator for managing non-HTTP workloads or ensuring reliable multi-region failover.

That's it for this blog, drop comments below in case of questions, suggestions or feedbacks. Thank you!

P.S. - Here's a reminder to drink water and stay hydrated!