fix: format markdown file

Author: Mufaddal5253110

content/blog/infrastructure-as-code-with-aws-cdk.md

@@ -21,7 +21,7 @@ AWS CDK, which is built on TypeScript, is tightly integrated with AWS CloudForma
 
 To get the most out of AWS CDK, it's essential to understand three fundamental concepts: Apps, Stacks, and Constructs. These concepts are the foundation of CDK, and understanding them will help us decide when to use the tool and how to structure our infrastructure as code.
 
-###  Apps (CDK Apps)
+### Apps (CDK Apps)
 
 A CDK App represents the root of our infrastructure as code, an entry point of our program. It's a composite of all the required resources for our application. Think of it as the top-level container that holds everything together. An App can contain multiple Stacks, which we'll discuss next.
 
@@ -34,6 +34,7 @@ In CDK, a Stack is the unit of deployment. It represents a single cloudformation
 A Construct represents a "cloud component" and encapsulates everything AWS CloudFormation needs to create or update a resource or a combination of resources. A Construct can have multiple resources that are coupled together, and a Stack can have multiple Constructs. Think of a Construct as a self-contained module that defines a specific piece of our infrastructure.
 
 Here's a simple analogy to help illustrate these concepts:
+
 * An App is like a city, which contains multiple neighborhoods (Stacks).
 * A Stack is like a neighborhood, which contains multiple houses (Constructs) and other infrastructure (resources).
 * A Construct is like a house, which is composed of multiple rooms (resources) and has its own architecture and configuration.
@@ -49,15 +50,17 @@ As we discussed about CDK, there is much more information available in the offic
 
 Our use case involves deploying multiple applications on AWS ECS, with each application using RDS Postgres as its database. The twist was that we had to deploy these applications multiple times for different clients, with each client requiring database isolation. This meant that we needed a solution that could efficiently manage multiple deployments with minimal effort.
 
-### The Requirements:
+### The Requirements
+
 * Deploy applications on AWS ECS
 * Use RDS Postgres as the database
 * Ensure database isolation for each client
 * Deploy the same application multiple times for different clients
 * Minimize onboarding effort for each new client
 * Manage multiple environments (lower and higher) with similar infrastructure components, but with configuration changes
 
-### The Challenge:
+### The Challenge
+
 To illustrate the challenge, let's consider an example. Suppose we have a bill generator service that needs to be deployed for multiple clients. The application code remains the same, but each client requires its own isolated database. We could either deploy the application on our own AWS infrastructure or on the client's AWS environment. However, this would require manual effort and configuration for each new client, which wasn't scalable.
 
 ### The Solution: AWS CDK to the Rescue
@@ -86,6 +89,7 @@ To illustrate the challenge, let's consider an example. Suppose we have a bill g
 7. **Stateful Resource Updates**: Updating stateful resources can be challenging, as it often requires recreating the resource, which involves destroying the existing one first.
 
 ## When to Choose CDK?
+
 1. **Reusable infrastructure**: Bundle infrastructure and reuse across multiple environments with minimal configuration changes.
 2. **Infrastructure and app code together**: Keep infrastructure and application code in one place and written in the same programming language.
 3. **Multi-tenant deployments**: Easily create deployments for multiple clients with minimal effort.
@@ -94,19 +98,23 @@ To illustrate the challenge, let's consider an example. Suppose we have a bill g
 ## Recommendations
 
 ### Modeling with Constructs and Deploying with Stacks
+
 A Stack is the unit of deployment, meaning that everything within it is deployed together.
 
 **Example: Machine Learning Model**
 A machine learning model can also be modeled as a Construct and deployed as a Stack. The Constructs that make up this model include an Amazon S3 bucket for storing training data, an Amazon SageMaker notebook instance for model development, and an Amazon SageMaker endpoint for model deployment. These Constructs can be composed into a single high-level Construct, such as MachineLearningModel. This Construct can then be instantiated in one or more tacks for deployment, depending on the environment (e.g., dev, prod, staging).
 
 ### Avoid Changing the Logical ID
+
 The logical ID is a unique identifier generated by AWS CDK for each resource in our Stack. Changing the logical ID of a stateful resource can lead to unintended consequences, such as
 
 * **Resource recreation**: If the logical ID changes, AWS CDK may recreate the resource, resulting in data loss or inconsistencies.
 * **Resource conflicts**: Changing the logical ID can cause conflicts with existing resources, leading to errors or unexpected behavior.
 
 ### Use Generated Resource Names
+
 It's recommended to use generated resource names instead of physical names defined while resource creation which can lead to several issues, including: Resource recreation, Resource conflicts, Tight coupling
 
 ## Conclusion
-Our experience with AWS CDK, we were able to achieve true "infrastructure as code." Our CDK codebase became the single source of truth for our infrastructure, allowing us to manage and version-control our environments with ease. This approach also enabled us to automate our deployments, reduce manual errors, and improve our overall efficiency.
+
+Our experience with AWS CDK, we were able to achieve true "infrastructure as code." Our CDK codebase became the single source of truth for our infrastructure, allowing us to manage and version-control our environments with ease. This approach also enabled us to automate our deployments, reduce manual errors, and improve our overall efficiency.