Continuous Integration/Continuous Deployment (CI/CD) is a set of software development practices that involves automating the process of integrating, testing, and deploying code changes to production. CI/CD pipelines have become the industry standard practice in modern software development, allowing organizations to deliver software faster and with higher quality.

Continuous Integration (CI) refers to the process of integrating code changes into a shared repository such as GitHub, building the application, and testing it automatically to ensure that the code is error-free and ready to be deployed. The aim is to catch any conflicts and errors early in the development phase.

Continuous Delivery (CD) takes a step further and deploys these changes to a development or production environment. The goal here is to deliver the application to the end-user in the fastest manner and shorten the feedback loop.

Why is CI/CD needed?

Here’s a closer look into the benefits of CI/CD and why they have become the industry standard process.

1. Short release time: Automating the process of integrating and deploying code changes allows for quicker and more frequent releases, enabling faster time-to-market and the ability to respond to user feedback and change requirements more efficiently.

2. Early detection of issues: By integrating and testing code changes regularly, CI/CD helps catch bugs, errors, and conflicts early in the development process, reducing the risk of issues reaching production.

3. Increased collaboration: CI/CD ensures collaboration among team members by encouraging regular integration of code changes and resolving conflicts early. This leads to better communication, coordination, and teamwork among developers.

4. Improved software quality: By automating testing and deployment, CI/CD helps ensure that only high-quality, thoroughly tested code reaches production, resulting in more stable, secure, and reliable software.

5. Greater agility and innovation: CI/CD enables teams to quickly adapt to changing requirements and market conditions, promoting innovation and the ability to continuously improve the software product.

Demo : AWS CodePipeline for a Java Web app

There are several CI/CD tools available today such as Jenkins, GitHub Actions, GitLab CI/CD, CircleCI, Bamboo, Azure DevOps, etc each having their own strengths and weaknesses. In this blog, we will use AWS CodePipeline which integrates well with other AWS services to create the CI/CD pipeline for a sample Java web app served by Tomcat. Feel free to read further as the process is very similar for other web applications such as Node.Js, Django, .NET, and Laravel.

Prerequisites

Before we begin, make sure you have the following prerequisites:

1. An AWS account with appropriate permissions to create and configure CodePipeline, CodeBuild, and Elastic Beanstalk resources.

2. Source code for your application. You can use our sample application for demo purposes.

   💡

   GitHub Repo: GitHub - adexltd/aws-ci-cd: Sample Java Maven Application for AWS CI/CD Demo!

We will use the following AWS services to create the pipeline:

1. AWS CodePipeline: A fully managed CI/CD service that automates the building, testing, and deployment of applications.

2. AWS CodeBuild: A fully managed build service that compiles source code, runs tests, and produces software packages ready to deploy.

3. AWS Elastic Beanstalk: Elastic Beanstalk is a fully managed service that makes it easy to deploy, manage, and scale applications in the AWS Cloud. It will handle the process of provisioning and maintaining underlying required infrastructure such as EC2, S3, and ASG based on our application environment.

High-Level Architecture and Process Flow

Flow Description

As seen from the diagram above, the pipeline will be triggered automatically whenever there is a code change in the source repository. AWS CodeBuild will then take this source code and build the application with applied configurations. This generates an application package (artifact) and stores it in S3 Bucket. Finally, in the deployment phase, Elastic Beanstalk will pull the artifact from S3 and launch the application from the bundle in the pre-defined environment. Additionally, CloudWatch produces the logs from CodeBuild that we can use for monitoring the build process. That concludes our flow.

Step by Step Implementation Guide

Step 1: Create an Elastic Beanstalk Environment

1. Open the AWS Management Console, navigate to the Elastic Beanstalk service, and click the "Create application" button. This will launch a configuration wizard.

2. In the first step, choose the "Web Server environment" as the environment tier.

3. Now, you can select the appropriate options for our application, such as platform, platform version application code source, and presets. We will go will the “Single Instance” preset as it is free tier eligible.

For our sample application: we have the following settings:

Application name : ci-cd-demo
Environment name : Cicddemo-env
Platform: Tomcat 8.5 
Platform Version : 4.3.7

4. Next, you can configure service access. Here, we will create a new service role. Optionally, you can add EC2 key pair to access EC2 servers deployed by Elastic Beanstalk.

5. Next, we will use the default options and select “Skip to review”. If you wish, you can set up networking (selecting custom VPCs, assigning Public IP to our EC2 instances), and create databases and tags. You can also choose the capacity of Auto Scaling Group, and configure monitoring and logging through CloudWatch metrics.

6. Review the configurations and click the "Submit" button to create the Elastic Beanstalk environment.

Step 2: Create a buildspec.yml file for CodeBuild

The buildspec.yml file is a configuration file that defines the build steps for your application and is used by CodeBuild to execute the build process (we will see the use of CodeBuild later). In your source code repository, create a buildspec.yml file at the root level of your project directory. This file contains the build steps for your application, such as building and testing your code.

Here is a buildspec.yml file for our sample application:

version: 0.2
phases:
  pre_build:
    commands:
    - echo "Pre-Build Phase"
  build:
    commands:
      - echo "Build Phase Started"
      - mvn clean package
  post_build:
    commands:
      - echo "Build Succeded"
artifacts:
  files:
    - target/aws-ci-cd*/*
  discard-paths: yes

This buildspec.yml file specifies three build phases: build, test, and post_build. If you are using another web framework such as Node.js, you can install your dependencies in the pre_build stage.

Here, we build our maven package in the build stage which creates the build artifact in the target/aws-ci-cd directory. The artifacts section of the build specification file provides details about where to store the artifacts and the format in which they should be stored.

By default, CodeBuild stores the build artifacts in an S3 bucket created and managed by CodeBuild. The S3 bucket is named with a prefix codepipeline-* followed by a unique identifier for the CodeBuild project.

You can also configure the build project to use a custom S3 bucket for storing the build artifacts. In our case, target/aws-ci-cd*/* pattern will be used to include files from the target directory that match the aws-ci-cd*/* pattern. Once the build process is complete, the resulting artifact files will be uploaded to the S3 bucket created by CodeBuild.

We can customize the buildspec.yml file based on the requirements of the application, such as adding additional build steps, tests, or deployment instructions. Make sure to commit and push the buildspec.yml file to your source code repository if you have not already.

Step 3: Set up a CodePipeline

Now, let’s set up a code pipeline that glues together everything we have done so far and deploy our application to ElasticBeanStalk

1. Open the AWS Management Console, navigate to the AWS CodePipeline service, and click the "Create pipeline" button.

2. Enter a pipeline name, and create a new service role.

3. Next, in the Source Stage, select your source provider (GitHub v2), and choose the repository and branch that you want to use for your application source code.

4. You might need to create a connection to GitHub if you are doing this for the first time. Give a connection name and click on “Install a new app” that will install AWS Connector for GitHub. Once connected, make sure the change detection option is checked to trigger the pipeline from the source code change.

5. Next, in the Build Stage select AWS CodeBuild as your build provider, and select “Create Project” option. Here, we will configure a CodeBuild project that will compile the source code, run tests (if present), and produce a software package that is ready to deploy.

• (Build Stage Continued): Enter the project name and choose a runtime environment for your build, such as Node.js, Java, or Python, and specify the build configurations. We will choose the following configurations.

• (Build Stage Continued) : Remember, we created buildspec.yaml earlier? It comes into use here. We will choose the “Use a buildspec file” option which in turn will look for buildspec.yaml in our repository root by default. Make sure to rename it if you have any other name for the build spec configs.

• Optionally, you can configure additional build options such as webhook triggers, CloudWatch Logs, and S3 Logs. Review your project configuration, add environment variables (if any), select “Buid type” as Single build, and click the "Continue to CodePipeline".

5. In the Deploy Stage, select AWS Elastic Beanstalk as your deployment provider, and choose the environment which we created in Step 1.

6. Finally, review your pipeline configuration and click the "Create pipeline" button to create your pipeline.

Step 4: Test the CI/CD pipeline

Now that we have set up the entire CI/CD pipeline, it's time to test it by making changes to your application source code and triggering a pipeline run.

1. Make changes to your application source code, such as fixing a bug, adding a new feature, or updating a configuration file. Here, I will just change the welcome message in /src/main/webapp/index.jsp to “Welcome to CI/CD!”

2. Commit and push the changes to GitHub or your source repository. This will trigger the pipeline to run automatically.

3. 

   Open the AWS CodePipeline service, and navigate to your pipeline to see the status of different stages. Here, we have used two environments for deployment. You might only see one if you have not created a new Beanstalk environment and added it to the pipeline.

4. CodePipeline will automatically start the build process in CodeBuild, which will compile our source code, run tests, and produce a deployment package. Once the build is successful, CodePipeline will automatically deploy the application to Elastic Beanstalk according to the deployment settings.

5. Monitor the pipeline run in the CodePipeline console, and check the build details from CodeBuild or Elastic Beanstalk environment events and logs for any errors or issues.

6. 

   Once the deployment is complete, we can access the application on the Elastic Beanstalk environment URL to verify that the changes have been successfully deployed.

Conclusion

Implementing a CI/CD pipeline is a crucial step in modern software development practices to ensure efficient and reliable application delivery. We explored AWS’s powerful tools like CodePipeline, CodeBuild, and Elastic Beanstalk which can be easily integrated to set up a robust CI/CD pipeline on the cloud. By following these steps, you can easily automate the process of building, testing, and deploying your applications, saving time and ensuring consistent quality in your software releases.

Resources

AWS CodePipeline: https://aws.amazon.com/codepipeline/

CodeBuild buildspec specification: Build specification reference for CodeBuild - AWS CodeBuild

Official Hands-on: https://aws.amazon.com/getting-started/hands-on/continuous-deployment-pipeline/

If you've landed here, you're likely familiar with the AWS landscape and planning to add that certification to your portfolio! If that sounds like you, you're in the right place. To be honest, the AWS Certified Solutions Architect Associate is not a walk in the park unless you have 1-2 years of professional experience and can visualize AWS architecture in your head.

However, it's not overly difficult either. I like to think of it as both challenging and rewarding. As someone who scored 961 out of 1000 on the exam with just over 4 months of professional experience (at the time of the exam), I am eager to share my experiences, learning approach, resources I used, and insights to help others pursue this certification.

About the Exam

The AWS Certified Solutions Architect Associate (SAA C03) exam is designed to assess your knowledge and skills in building scalable and reliable AWS solutions. It covers a range of topics, including designing and deploying systems, implementing cost-effective solutions, and understanding security best practices. They also test you heavily on the AWS Well Architect Framework. So yes! you need to be aware of various AWS services and be able to decide the best combination depending on specific scenarios.

Instead of focusing deeply on the code level or infrastructure implementation and debugging (which is mostly the case with the Developer Associate exam), the SAA C03 exam focuses on how you approach the given problem keeping in mind the six pillars of AWS Well Architect Framework. The four major domains for the exam are:

• Domain 1: Design Secure Architectures

• Domain 2: Design Resilient Architectures

• Domain 3: Design High-Performing Architectures

• Domain 4: Design Cost-Optimized Architectures

The format for the exam is 65 Multiple Choice Questions (MCQs) and you get 130 minutes to complete it. It will cost you about $150, and you can take it online at your home or from a verified testing center. Find more details about the exam on their official page.

Learning Approach

Well, now you know about the exam and what it tests! Let's take a look at the learning approach I used. The preparation took me around 1.5 months studying about 1-2 hours per day alongside my full-time job. This might be more if you are just setting your footprints in AWS and less if you are already a pro.

1. Set Clear Goals:

Before diving into study materials, define your goals and why you need the certification in the first place. Is it a part of your job, are you trying to get hired or improve your portfolio? You also need to make sure that you align yourself with the exam objectives. Maybe there's another certification that's more suited to you. This is what will motivate you to study.

2. Structured Study Plan and Consistency:

Develop a structured study plan. Allocate specific times each day or week to cover different topics. Identify the areas where you need to work more. For me, this was cost-optimization and serverless domain. Remember that consistency is key here.

3. Hands-On Practice:

Apply theoretical knowledge that you have gained through hands-on practice. This is super crucial. Unless you don't apply what you learn, you can't relate the pain points and the problem you are solving. YES! I understand you can't use every AWS service that's out there and what exam tests you on. But, you need be be at least proficient with common services such as EC2, S3, VPC, Lambda, IAM, Cloudformation, ECS, RDS, etc, and be aware of others. Note that AWS offers a free tier that allows you to experiment with various services without incurring charges.

4. Use Multiple Resources:

Don't rely on a single source. Combine official AWS documentation, online courses, and practice exams to gain a well-rounded understanding and consume diversified content. This is the single most important tip for you all.

5. Join Forums and Communities:

Engage with the AWS community. Participate in forums, and discussion groups, and attend webinars. You can also watch the content from AWS YouTube where they post really interesting videos on various AWS services and architectural patterns. I found their This is My Architecture Playlist very helpful.

Resources - Official

Alright! Now you know the approach to ace your exam. But hey, can you also tell me the resources you used? Sure, here's the list of the official resources I used. These are also the free ones.

1. AWS Technical Essentials: For clearing basic concepts on all the major topics (Recommended if you are getting started)

2. AWS Certified Solutions Architect - Associate Exam Guide: Has clear documentation on the EXAM domains, the specific skills they are looking for, and the relevant services you need to focus on.

3. AWS Certified Solutions Architect - Associate Sample Questions: 10 questions to give you an idea of the questions and their complexity.

4. AWS Certified Solutions Architect - Associate Official Practice Question Set: 20 additional questions that supplement the sample questions

5. Exam Prep: AWS Certified Solutions Architect - Associate: 3-hour free course on SkillBuilder directly from AWS themselves.

6. WAFR WhitePapers: Take your time to read this. It is more than 800 pages, and you do not need to learn everything. Just focus on understanding the six pillars and how you can incorporate them.

   (Below are the recommended resources though I did not use them personally for my exam)

7. AWS Power Hour: Architecting on-demand - Twitch Recordings with six episodes that cover various domains from the exam with great use cases

8. AWS Service FAQs - Whenever you use any AWS Service, try to also read the FAQs such as the EC2 FAQ. I found some questions on the exam that were answered in the FAQ Section.

Resources - Others

While official resources are the source of truth and are highly recommended, many of us prefer a guided approach with dedicated courses, practice sets, and a community to discuss and share learnings. I am no exception. Here's the list of third-party resources I used:

1. Stephane Mareek Udemy Course: Simply the best and my go-to resource for learning the exam contents. His way of explaining things in simple terms is phenomenal. If there's one course you want to purchase, this would be the one! He also got the five full-length Practice Sets though I found them to be a bit tougher than what's tested on the exam. But this will prepare you well.

2. Examtopics Question Bank: They have an arsenal of exam-like questions and almost half of the questions are available for free. Highly Recommended to consume those. I found the exam questions to be very similar to the ones here.

3. WhizLabs Practice Sets: Again, this is a great source for practice sets. If you already have a WhizLabs subscription, do try out this. They have several full-length sets where you can test your skills. Take this as an optional resource if you don't want to buy it.

4. r/AWSCertifications: A great community for interacting and engaging with other test-takers and experts. They do joke around a lot, but sometimes even the joke teaches you a lot (chuckles)

Below are some additional resources worth mentioning, as recommended by my colleagues and the community, though I did not personally purchase them:

1. Tutorials Dojo Udemy Course

2. Neal Davis Udemy Course

Exam Day Experience and Tips

I took my exam on 7th August 2023 and you can see my results below.

To be honest, I was not expecting to score that high, but was happy when I got those scores back in about 8 hours. I took my exam at a testing center and it was scheduled at around 11 AM. Overall, it was a pleasant experience as the center was not very crowded and there were no distractions at all. Here are my tips for D-Day.

1. Request for additional 30 minutes

If you are from a country where English is not the native language, you can request AWS for an extra 30 minutes for your exam during registration. DO NOT miss out on this opportunity if you are eligible (ESL +30).

2. Reach your test center early

I reached my center about 25 minutes before the exam. My center was pretty calm with not much crowd. Also, I was the only test taker at that time slot, so the ID Checks and verification process went smoothly. But, this might not always be the case for you. So, try to reach your test center at least 30 minutes to provide you ample time for smooth check-ins.

3. Flag and Review

Manage your time wisely during the exam. Some questions are intentionally more difficult than others and may require more thought. So don't spend too much time on a single question. Just choose the one that your instincts suggest, mark it for review (yes! You can flag them), and come back to it later on.

4. Read Carefully:

Pay close attention to each question. Most questions are scenario-based, and sometimes missing a crucial detail such as cost in the phrase "clients want the most cost-effective solution" can lead to incorrect answers. An example could be the use of EC2 in Multi-Region for high availability. But this is not a cost-effective solution.

5. Stay Calm:

Stress can hinder your performance, I for sure was stressed about 8-10 questions that I had doubts about. But not spending too much time on them, taking deep breaths at times, and analyzing them later on with a fresh perspective helped.

Conclusion

Thank you for reading! Achieving AWS Certified Solutions Architect Associate status is both challenging and rewarding. A structured study plan, diverse resources, and hands-on experience are the keys to acing your exam. Remember, the journey doesn't stop here. Continuous learning and active engagement with the AWS community will further enrich your experience and knowledge. As we conclude, I'm curious to know your favorite resources for the SAA-C03 Exam. Share them in the comments below.

Best of luck on your path to AWS Certification Success! Stay tuned for more insights and guides by following my blog and subscribing to my newsletter. Don't forget to check out my YouTube channel for informative videos on DevOps and Cloud!

Amazon Elastic Container Service (ECS) is a powerful container orchestration service that enables you to run containers in a highly scalable and cost-effective manner.

ECS Exec is a feature provided by AWS Systems Manager that leverages the AWS Identity and Access Management (IAM) role associated with your ECS task to grant you secure access to your containers

In this blog post, we will explore how to leverage ECS Exec to access containers running on both Fargate and EC2-backed ECS tasks.

The Need

Picture this: You are a cloud engineer overseeing a fleet of containers running smoothly on Amazon's Elastic Container Service (ECS). Everything seems under control until one of your containerized applications starts throwing errors during peak traffic hours. You checked everything on your monitoring solution such as CloudWatch and it does provide information of substance. Or, perhaps, you need to run some commands and interact with various processes on your containers.

Either way, you need a way to quickly execute into the container. One solution is to SSH into the EC2 host running the containers and then perform docker exec against the container. But wait, Fargate does not even allow direct SSH. So, what now? There comes ECS Exec into play, a relatively new functionality, released by AWS in March 2021, that allows users to either run an interactive shell or a single command directly against a container.

For ECS running on EC2, this also removes the need for SSH or direct access to the host. This capability simplifies container management and makes it easier to diagnose issues, gather logs, and perform other necessary tasks.

Pre-requisites

Before you can start using ECS Exec, you need to ensure you have the following in place:

1. An AWS ECS Cluster: You should already have an ECS cluster set up with one or more tasks running, either on Fargate or EC2 instances.

2. IAM Permissions: Ensure that the IAM roles associated with your ECS tasks have the necessary permissions to use Systems Manager. Specifically, you need the ssm:StartSession permission.

3. Systems Manager Agent (SSM Agent): SSM Agent should be installed and running on your container instances. It comes pre-installed on most Amazon Machine Images (AMIs) provided by AWS.

4. AWS Systems Manager Session Manager Plugin: You should have the AWS Systems Manager Session Manager plugin installed on your local machine. This plugin enables you to initiate ECS Exec sessions from your terminal.

5. Note: ECS Exec is not currently supported using the AWS Management Console.

Steps

Now, let's walk through the steps to access your containers using ECS Exec:

Step 1: Set Up AWS Systems Manager Session Manager Plugin

If you haven't already installed the AWS Systems Manager Session Manager plugin on your local machine, you can follow the official AWS documentation to do so. This plugin is available for various operating systems, and installation is straightforward.

Step 2: Access Your Container

Once the Session Manager plugin is installed, you can access your container using the aws ssm start-session command. Here's a basic example:

aws ecs execute-command  \
    --region $AWS_REGION \
    --cluster <cluster-name> \
    --task <task-id> \
    --container <container-name> \
    --command "/bin/bash" \
    --interactive

Step 3: Execute Commands

After initiating the session, you'll be presented with a shell prompt that allows you to execute commands inside your container. You can run diagnostics, check logs, or make configuration changes as needed.

Step 4: Exit the Session

When you're done, simply type exit to exit the session.

Step 5: Clean Up (Optional)

It's a good practice to clean up unused sessions and resources. You can do this through AWS Systems Manager.

Conclusion

ECS Exec, powered by AWS Systems Manager, is a valuable tool for container management and troubleshooting on Amazon ECS. It simplifies the process of accessing your containers running on Fargate and EC2, eliminating the need for SSH or direct host access. By following the prerequisites and steps outlined in this blog post, you can take advantage of ECS Exec to efficiently diagnose issues, collect logs, and perform maintenance tasks within your containers. This capability not only streamlines your container orchestration but also enhances your overall operational efficiency when working with ECS.

As you continue to leverage ECS Exec, you'll find it to be an essential part of your container management toolkit, improving your ability to maintain and troubleshoot containerized applications with ease.

Did you know that your AWS account, if it was created after 4th December 2013 has a default VPC in each AWS Region? In this blog, we will talk about the various characteristics of the default VPC, discuss its use cases, and see how you can create one from the AWS Console, CLI, and Terraform. We will also run through scenarios when you would not want to use the default VPC. So, let's get started 🚀

Why do we need AWS Default VPC?

First thing first, most if not all AWS resources require you to define or choose a Virtual Private Cloud (VPC) for it to run. VPC is the underlying foundation that creates a logically isolated virtual network for your resources. That's where the AWS Default VPC comes into play. So, instead of throwing a bunch of errors (such as missing subnets, no-internet connection, etc.) when you try to launch an EC2 instance or any other AWS service, it can use the default VPC and let you get that aah-hah deployment success message!

YES! You could create your own VPC and launch your resources there (we will cover this later in the blog)! But, what if you don't want to dive into understanding subnetting, setting up an Internet Gateway, Route Tables, etc? If this sounds scary enough, and you want to quickly get started, the default VPC comes to your rescue. You can immediately start launching your Amazon EC2 instances into a default VPC. You can also use services such as Elastic Load Balancing, Amazon RDS, Amazon ECS, Amazon EMR, and others in your default VPC.

Characteristics of AWS Default VPC

Alright! I got that. But what exactly makes up the Default VPC you may ask? Here's your answer:

1. IPv4 Address Space: IPv4 CIDR block (172.31.0.0/16). Notice the size /16 here. This provides a vast pool of 65,536 private IPv4 addresses, essential for scalability and resource allocation. Notice the IPv4 address space in the image below.

   

2. Subnets: Each Availability Zone (AZ) gets a dedicated /20-size public subnet, allowing for 4,096 IP addresses per subnet. Note that, all the EC2 Instances that you launch in a default subnet get both a public IPv4 address and a private IPv4 address, as well as both public and private DNS hostnames.

   

3. Gateway to the Internet: An Internet Gateway (IGW) that allows seamless connection between your VPC and the Internet, enabling secure and efficient communication. You also get a route in the main route table that points to all external traffic (0.0.0.0/0) to the internet gateway and internal traffic redirects to the VPC itself (local).

   

4. Security Measures: A default Security Group(SG) and a default Network Access Control List (NACL) that ensure a secure perimeter for your resources.

Customize your default VPC

If required, you can customize your Default VPC to align with your unique requirements which is often the case:

• Add additional IPv4 CIDR blocks (if you need more IP address space)

• Add nondefault subnets

• Modify Route Tables and add/remove routes

• Update rules in the default security group and/or add additional security groups, providing granular control over inbound and outbound traffic.

• Configure for AWS Site-to-Site VPN and Direct Connect Gateway

• Associate an IPv6 CIDR block

Access your default VPC and subnets

Well, thanks for that! Now, I know what default VPC is, why is it needed, and the various components. But, hey there 👋 how and where can I see it? I got you!

1. Navigate to the AWS VPC Console.

2. Access "Your VPCs" in the sidebar.

3. Check the "Default VPC" column for a Yes value.

   

4. Click on YOUR-VPC-ID and open "Resource Map" to check for the underlying default subnets, route tables, and IGW. Alternatively, you can navigate to Subnets and identify them from the "Default Subnets" columns

   

Creating Default VPC

Whoo! This looks interesting. So, can I create one if I don't have one already? Well, certainly. Let's look at three different ways of achieving this.

1. AWS Console: Navigate to "Your VPCs," execute "Actions," and select "Create Default VPC." You are all set to go!

   

2. AWS CLI: If you are more off of a CLI wizard, as you should be as a DevOps Engineer, you can use the following command to create a new default VPC.

    aws ec2 create-default-vpc
   

   💡

   Note that you would need to install AWS CLI and authenticate to your account to run the command. Read the configuration guide here

3. Terraform: If you do everything as IaC (Infrastructure as Code), you can create the same with the following Terraform Resource Block.

resource "aws_default_vpc" "default" {
  tags = {
    Name = "Default VPC"
  }
}

Can I delete a default VPC?

The short answer is YES! But be careful if that's what you want and only do so if you have custom VPC for your use cases. Otherwise, you might not be able to use many AWS services.

Can I make an existing VPC the default VPC or restore a deleted default VPC in Amazon VPC?

Here, the answer is NO! You cannot convert your existing non-default VPC to your default VPC. You also cannot restore a previous default VPC that you deleted.

Should I always use the default VPC?

Now this is the question you should be asking! While it's very easy to get started creating resources and get it up and running in the default VPC. Once you have multiple resources for different projects, especially in production, it is generally advised not to use default VPC.

This is because you can isolate your workloads on multiple dedicated VPC, say for instance your containers and your database in RDS can run on a separate custom VPC. This creates a logical separation and adds an extra layer of security. You also get much control over IP addresses and subnetting in custom VPCs. On top, most security audits will flag default VPCs, SGs, etc. Check out the tfsec flag details here

Conclusion

AWS Default VPC comes with predefined IPv4 addresses, subnets, IGW and other components to help you quickly get started with AWS services. It abstracts the creation of a custom VPC and provides you with a ready-to-use VPC. However, for production use cases, it's advised to create your own custom VPC for specific workloads and additional security.

If you like my blog, do follow and check out my videos on YouTube where I publish videos on DevOps and Cloud. Here's one about Docker Bridge Network that explains how containers communicate with each other and to the internet:

Resources

1. https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html

2. https://docs.aws.amazon.com/vpc/latest/userguide/default-security-group.html

3. https://aquasecurity.github.io/tfsec/v1.8.0/checks/aws/vpc/no-default-vpc/

4. https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/default_vpc