DEV Community: Mawuli Denteh

Create a cloud-backed IDE for development

Mawuli Denteh — Thu, 23 Oct 2025 23:32:19 +0000

Problem

I find it burdensome creating and configuring my development environment all over again when using a new laptop or system.

The need for speed when installing packages, extensions, and compiling code is also very important, and the network plays a big role in that.

After setting it all up, I also don’t want anything to disrupt the environment. I also want to be able to log in or access it reliably and easily anytime I need from any machine without having to set it all up again.

Having dealt with this scenario many times, I found a way to create this environment, call upon it when I need and put it off when I don’t — and also have the ability to back it up anytime I make progress with new states of the storage/system.

This may not be for everyone, but I think many developers may find value in this setup depending on their situation.

Solution

Create a Linux server in the cloud and use VS Code’s Remote SSH feature to securely access it, with the capability to manage the file system from the editor like you would locally.

I call it “The DevBox”. Sounds cool, doesn’t it? Let’s build it.

Cost Considerations

This solution is going to cost a roughly fixed amount per month for EBS storage and snapshots (minimal) and a variable amount for EC2 compute, depending on how many hours you keep the server up in a month.

Take note and check the cost of what you are going to build (using the AWS Pricing Calculator) based on how you will use it.

Step 1 – Create a Dedicated Network for the DevBox

I chose to create a small VPC with a /24 network, which is just ideal for this case.

You can optionally add an S3 Private Gateway Endpoint for no extra charge. This would be useful for copying files from authorized S3 buckets into your environment when needed.

I chose a simple public subnet design with a restricted instance security group allowing SSH access only from my IP address.

Step 2 – Create the DevBox EC2 Instance

You can go with the latest Amazon Linux AMI or Ubuntu 24.04 LTS, which I used in this setup.

Restrict SSH access to your IP in the security group for security.

Step 3 – Configure SSH Access in VS Code

Right-click the left panel of your VS Code editor and ensure the Remote Explorer is checked.

Right-click on SSH and open the config file.
Edit the config file as shown below:

User: Varies depending on the AMI you use.
IdentityFile: Points to the location of your key file.
HostName: The remote server IP address.

Connect in a new window.

Confirm the step by hitting the Enter key.

It should take a few seconds to connect and configure — and boom! You’re connected via SSH within VS Code, while utilizing cloud storage and networking.

Further Steps

Install your packages and set up your environment as needed.
Expand the storage as you grow.
Optionally add a second EBS volume as the data/working volume.
Connect to an S3 bucket within your account via the S3 Gateway.
Back up the volume, stop, and/or terminate the instance as needed.

Customize VPCs with CloudFormation Conditions

Mawuli Denteh — Mon, 13 Jan 2025 03:29:22 +0000

Using CloudFormation Conditions you can decide which resources to create/configure from your CloudFormation template.

In this post, we are going to build a template that can create a VPC with private subnets and a NAT gateway or only public subnets depending on a parameter when creating the CloudFormation stack.

Steps to create and use Conditions

Define the input parameters you want your condition to evaluate.
Define the condition by using the intrinsic condition functions.
Declare the condition in resources or outputs you want to create.

Let's dive into the example!

Define the parameter and condition

In the first part of our template, we'll define our parameter and condition.

We associate the CreatePrivateResources condition with a value/option from our CreateNatGateway parameter. This enables us to do what has been discussed in the intro above.

Parameters:
  CreateNatGateway:
    Type: String
    Description: "Need a NAT Gateway?"
    AllowedValues:
      - yes
      - no
    Default: yes

Conditions:
  CreatePrivateResources: !Equals
    - !Ref CreateNatGateway
    - yes

Define the public resources

Here, we will define our VPC, internet gateway, public subnets, routes and route tables. These resources will always be created. This is because they will not have any condition associated with them.

Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: "10.0.0.0/16"
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName}-VPC"

  # Public Resources
  InternetGateway:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName}-InternetGateway"

  AttachGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref InternetGateway

  PublicSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: "10.0.1.0/24"
      MapPublicIpOnLaunch: true
      AvailabilityZone: !Select [0, !GetAZs ""]
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName}-PublicSubnet1"

  PublicSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: "10.0.2.0/24"
      MapPublicIpOnLaunch: true
      AvailabilityZone: !Select [1, !GetAZs ""]
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName}-PublicSubnet2"

  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName}-PublicRouteTable"

  PublicRoute:
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: "0.0.0.0/0"
      GatewayId: !Ref InternetGateway

  PublicSubnet1RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet1
      RouteTableId: !Ref PublicRouteTable

  PublicSubnet2RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet2
      RouteTableId: !Ref PublicRouteTable

Use the condition

We now apply our condition to selected resources which creates a private environment for us, i.e. NatGateway, private subnets and routes etc. If we choose no at the prompt, these will not get created.

We also control the display of outputs using the same conditions.

# Private Resources
  NatGateway:
    Condition: CreatePrivateResources
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt EIPNatGateway.AllocationId
      SubnetId: !Ref PublicSubnet1
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName}-NatGateway"

  EIPNatGateway:
    Condition: CreatePrivateResources
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName}-EIPNatGateway"

  PrivateSubnet1:
    Condition: CreatePrivateResources
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: "10.0.3.0/24"
      MapPublicIpOnLaunch: false
      AvailabilityZone: !Select [0, !GetAZs ""]
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName}-PrivateSubnet1"

  PrivateSubnet2:
    Condition: CreatePrivateResources
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: "10.0.4.0/24"
      MapPublicIpOnLaunch: false
      AvailabilityZone: !Select [1, !GetAZs ""]
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName}-PrivateSubnet2"

  PrivateRouteTable:
    Condition: CreatePrivateResources
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
        - Key: Name
          Value: !Sub "${AWS::StackName}-PrivateRouteTable"

  PrivateRoute:
    Condition: CreatePrivateResources
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref PrivateRouteTable
      DestinationCidrBlock: "0.0.0.0/0"
      NatGatewayId: !Ref NatGateway

  PrivateSubnet1RouteTableAssociation:
    Condition: CreatePrivateResources
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnet1
      RouteTableId: !Ref PrivateRouteTable

  PrivateSubnet2RouteTableAssociation:
    Condition: CreatePrivateResources
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnet2
      RouteTableId: !Ref PrivateRouteTable

Outputs:
  VPCId:
    Description: "VPC ID"
    Value: !Ref VPC
  PublicSubnet1Id:
    Description: "Public Subnet 1 ID"
    Value: !Ref PublicSubnet1
  PublicSubnet2Id:
    Description: "Public Subnet 2 ID"
    Value: !Ref PublicSubnet2
  PrivateSubnet1Id:
    Condition: CreatePrivateResources
    Description: "Private Subnet 1 ID"
    Value: !Ref PrivateSubnet1
  PrivateSubnet2Id:
    Condition: CreatePrivateResources
    Description: "Private Subnet 2 ID"
    Value: !Ref PrivateSubnet2
  NatGatewayId:
    Condition: CreatePrivateResources
    Description: "NAT Gateway ID"
    Value: !Ref NatGateway

You can now customize your VPC creation just by changing a parameter.
Thanks for reading. Happy Building!

Create a load-balanced web server with auto-scaling

Mawuli Denteh — Wed, 06 Mar 2024 00:00:00 +0000

Overview

This tutorial walks you through the process of creating web servers, managed by an auto scaling group. The auto scaling group uses a launch template to create the servers. The auto scaling group launches the servers into a target group. An internet-facing load balancer directs traffic to the target group.

Architecture Diagram

1. Create a VPC

A VPC is an isolated, private network you can create to run your workloads. You have complete control over your VPC when you create one.

Click on Create VPC from the VPC Dashboard to create a new VPC.
Select VPC and more.
Enter a name under Auto-generate.
Choose a 10.0.0.0/16 IPV4 Cidr block.
Number of Availability Zones (AZs) = 2.
Number of public subnets = 2.
Number of private subnets = 0.
NAT gateways ($): None.
VPC endpoints = None.
Leave all other settings as default.
Click Create VPC.

Demo

2. Create a Launch Template

The launch template will serve as the blueprint for creating the exact type of server we need to meet our web server demands. A launch template can be modified to create new versions when you need to change a configuration.

Click on Create launch template from the EC2 console to create a new launch template.
Launch template name - required.
Check the Provide guidance to help me set up a template that I can use with EC2 Auto Scaling box.
Under Application and OS Images (Amazon Machine Image) - required, choose Amazon Linux 2023 AMI.
Instance type = t2.micro.
Key pair - Proceed without a keypair.
Subnet - Don't include in launch template.
Create security group.
Allow HTTP traffic from 0.0.0.0/0 (Ignore the warning about security group. We will edit it later).
VPC - Select the VPC you created.
Under Advanced network configuration, choose Enable under Auto-assign public IP.
Under Storage, leave all other configuration as default and choose "gp3" for Volume type.
Resource tags: optional.
Under Advanced details, scroll down to the User data section and enter the following lines of code exactly as shown:

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html
systemctl restart httpd
amazon-linux-extras enable epel
yum install -y stress
cat << 'EOF' > /home/ec2-user/start_stress.sh
#!/bin/bash
sleep 240
vcpus=$(nproc)
workers=$vcpus
stress --cpu "$workers" --timeout 300
EOF
chmod +x /home/ec2-user/start_stress.sh
nohup /home/ec2-user/start_stress.sh > /home/ec2-user/start_stress.log 2>&1 &

Demo

3. Create Target Group

A target group will route requests to the web servers we create. Our load balancer will need this target group to know what set of servers to distribute traffic to. Our auto scaling group will also be associated with this target group so it launches our servers into the target group.

Click on Create target group from the EC2 console to create a target group.
Choose a target type: Instances.
Target group name: Enter a name.
Protocol: HTTP.
Port: 80.
VPC: Select the VPC you created.
Leave every other value on this page as default. Next
Register Targets: Leave as is.
Click Create target group.

Demo

4. Create Load Balancer

An application load balancer acts as the entry point for traffic to our web servers. Instead of allowing users to access our application directly, we will use the load balancer to distribute traffic equally among our autoscaling group of web servers. This is better for load management, security and reliability of our application.

Click on Create load balancer from the EC2 console to create a load balancer
Type: Application Load Balancer.
Scheme: Internet-facing.
IP address type: IPV4.
VPC: Select the VPC you created.
Mappings: Check the box beside the two AZs listed.
Subnet: For each AZ selected, choose the public subnet in the dropdown menu.
At this point, go to the Security groups console and create a new security group for the load balancer. The inbound rule should allow HTTP traffic from anywhere.
Select this security group as the load balancer security group.
Listeners and routing: Leave protocol and port as HTTP:80. Select the target group you created as target group.
Leave every other config as default and click Create load balancer.

Demo

5. Create Auto Scaling Group

The auto scaling group configures and controls how your application scales automatically in response to varying traffic situations.

Click on Create Auto Scaling group from the EC2 console to create an auto scaling group.
Enter a name.
Choose the launch template you created. Click Next.
Select your webserver VPC created from the VPC step.
Under Availability Zones and subnets, select the two public subnets in your VPC, in different AZs. Click Next.

NB: Note that you can use the auto scaling group to override your instance type config from the launch template*.

Under Load balancing, choose the option Attach to an existing load balancer.
Select Choose from your load balancer target groups.
Select the target group you created.
Select VPC Lattice service to attach: No VPC Lattice service.
Additional health check types - optional: Turn on Elastic Load Balancing health checks.
Leave every other config as default. Next.
Group size: Desired: 2, Minimum: 1, Maximum: 4.
Scaling policies: Target Tracking Policy.
Metric type: Average CPU Utilization.
Target Value: 50%.
Create Auto Scaling Group.

Demo

Once you successfully create your autoscaling group, you should see two new instances in the EC2 console. This is because we specified a desired count of 2. Also note that they are automatically placed one in each AZ to support high availability.

Restrict web traffic to servers

With the current design, users can directly access our web server using its IP address. We don't want that. That is why we created a load balancer.

To ensure all incoming HTTP traffic goes through the load balancer, we will update the webserver security group to accept HTTP traffic only from our application load balancer security group.

Go to the autoscale-webserver-sg security group and click on Edit inbound rules.
Delete the existing HTTP rule.
Add a new HTTP rule. In the Source box, scroll down to select the security group of the load balancer. Save rules.
You have successfully restricted traffic going to the servers to the load balancer.
You should no longer be able to access your web server using the server IPs or DNS names. You should now be able to use the load balancer DNS name to access the servers. Test this out.

Observations

From the details tab of the load balancer, copy the DNS name and paste in a new tab. Refresh the tab and note the changing hostnames with every refresh. That's the load balancer alternating traffic between its target web servers.

After launching the desired number of instances, a bash script will run in the background to increase CPU utilization to 50%. This will trigger a scale out action.

This should lead to a maximum number of 4 instances being available to serve web traffic.

When the script stops running, a scale in action should equally be triggered to reduce the instances back to the desired number.

It takes about an hour to observe this.

Conclusion

You have built a load-balanced and highly available web application that auto-scales based on a target of CPU utilization.

Delete the autoscaling group and load balancer after your tests to prevent unwanted charges.

If you made it this far, here's a little reward:

The CloudFormation stack below will deploy exactly what you have built in the demo. Try it out.

Download IAC template