DevOps Posts

AWS CloudFormation Stack Policy Conditions: Don't Replace or Delete My DB Instances on Stack Updates

AWS CloudFormation Stack Policy Conditions: Never Replace or Delete My DB Instances on Stack Updates

Stack policies are among the most helpful features of AWS CloudFormation for protecting your stacks from unintended updates. Let’s say that you have an Amazon RDS instance that you manage with AWS CloudFormation. After a while, you change one of its attributes and update your stack. Guess what! The update you considered innocent was not so after all. It replaces your database instance with all the data inside. It’s a nightmare, isn’t it? So, you wish there were a CloudFormation feature preventing this from happening.

Luckily, CloudFormation has stack policies to help you in situations like this. In this post, I will talk about stack policies and how to use them as a supplementary protection mechanism in your stack updates. Read more at AWS CloudFormation Stack Policy Conditions: Don't Replace or Delete My DB Instances on Stack Updates post.

CI vs. CD: What are Continuous Integration, Delivery or Development?

CI vs. CD - Continuous Integration, Delivery or Development

Today, applying CI/CD is one of the most crucial DevOps practices. CI means Continous Integration, whereas CD can be applied as either Continuous Development or Continuous Deployment. Sometimes the terminology may seem confusing and people talking about them often assume that you know them from the beginning. So, as a developer applying CI/CD for years and having launched a course about the native CI/CD solution of AWS, AWS CodePipeline, I may help you understand these DevOps concepts. In this post, I will discuss what CI and CD practices mean and explain their differences. Read more at CI vs. CD: What are Continuous Integration, Delivery or Development? post.

Configuring Amazon EC2 Instances With AWS CloudFormation

Managing Amazon EC2 Instance configurations With AWS CloudFormation

In this blog, I talk about the benefits of defining your infrastructure as code using AWS CloudFormation from time to time. You define the properties of your AWS resources in a template and create a stack from it. When you need an update, you edit your template accordingly and update your stack. Don’t need a resource anymore? Just remove it from your template and update your stack again. Or, delete your stack if you no longer wish to keep any of its resources. In an ideal scenario, you keep your infrastructure code, your CloudFormation templates, in the same repository as your project and use a CI/CD pipeline to deploy it.

You can manage most AWS resources with AWS CloudFormation like this. However, Amazon EC2 instances are somewhat different. Again, you have properties like the subnet, instance type, or security groups of an EC2 instance as in other resource types. But, you also make custom, OS-level changes after creation, such as installing software packages, downloading or configuring files, etc. Besides, you may need to update this configuration later. It is why configuring an EC2 instance with CloudFormation needs more attention, and we have a dedicated section about it in my AWS CloudFormation Step by Step: Intermediate to Advanced course.

In this post, I will summarize how to manage EC2 instances using AWS CloudFormation. Firstly, we will discuss the UserData property. Then, we will continue with AWS CloudFormation helper scripts: cfn-signal, cfn-init and cfn-hup. We will also see the CreationPolicy attribute along the way. So, let’s start! Read more at Configuring Amazon EC2 Instances With AWS CloudFormation post.

Deploying CloudFormation Nested Stacks With AWS CodePipeline & AWS CodeBuild

Deploying AWS CloudFormation Nested Stacks with AWS CodePipeline

AWS CodePipeline provides AWS CloudFormation Create or update stack and Create or replace change set action types to deploy your CloudFormation stacks from your pipeline. If you have joined my AWS CodePipeline Step by Step course, you would remember our example there. We automatically create a staging stack from a CloudFormation template before the manual approval action in our pipeline.

However, AWS CodePipeline’s CloudFormation action types only create stacks from deployable stack templates. Therefore, you cannot deploy your CloudFormation nested stacks with local path template definitions directly without packaging and uploading them to an S3 bucket first. In this post, I will talk about achieving this on an AWS CodePipeline pipeline using AWS CodeBuild. Read more at Deploying CloudFormation Nested Stacks With AWS CodePipeline & AWS CodeBuild post.

Amazon CloudWatch Alarms vs. Events (or EventBridge)

Amazon CloudWatch Alarms vs Events (EventBridge)

If you maintain an application on AWS, you may have heard about Amazon CloudWatch already, the monitoring service of AWS. Amazon CloudWatch gathers metrics from your AWS resources such as CPU or memory usage, and your resources emit events to CloudWatch when their states change, such as an auto-scaling launch event.

You can define thresholds on your metrics and trigger alarms if those thresholds are exceeded. Besides, you can take actions on a specific event, for example, by triggering an AWS Lambda function. Hence, both features help you in monitoring the states of your resources and get notified or take proactive or reactive actions to protect the health of your workload.

Whether you are planning to use Amazon CloudWatch for the first time or preparing for an AWS exam these days, you may be wondering what the differences between these two crucial Amazon CloudWatch features are.

By the way, Amazon EventBridge is the new version of Amazon CloudWatch Events, so the topics we will talk about in this post will also be valid when comparing Amazon EventBridge with Amazon CloudWatch Alarms. So, what are the differences between Amazon CloudWatch Alarms and Events?

Read more at Amazon CloudWatch Alarms vs. Events (or EventBridge) post.