Introduction.

The capacity to manage scalability properly is crucial in the dynamic world of cloud computing. Elastic Load Balancing and Amazon EC2 Auto Scaling allow you to seamlessly integrate and improve your infrastructure. You may effectively spread traffic and guarantee high availability by adding Application Load Balancers, Network Load Balancers, or Gateway Load Balancers to your auto-scaling group.

In this technical post, we go into the nuances of securing an application load balancer to auto-scaling groups and also target group creation and health check implementation, providing helpful information to optimize your setup.

Services Required.

• IAM role with 2 permissions

• S3 to upload my source code to a bucket

• 1 EC2 instance, and an AMI of the instance

• Elastic Load Balancer

• Auto-Scaling Group

Steps.

1. Log in to your AWS account.

2. Navigate to S3 and create a bucket (with a unique name).

3. Upload source code to the S3 bucket.

4. Navigate to the IAM dashboard and create a role with permission to have access to s3.

5. Navigate to EC2 to launch an instance, Give your instance a name.

6. Choose a free-tier eligible instance type and add a key pair (which will be used to connect to your instance).

7. Add an already existing security group (which is a firewall for my EC2 instance).

8. Add user data, which is a script that runs only once at the start of my instance.

9. I edited my user data because I had issues viewing my instance through the public IP because of some wrong syntax on the last line (this was a challenge as it took me time to realize).

10. My site is visible after corrections.

11. I created an AMI from my instance.

12. Time to create a load balancer (an application load balancer in this scenario), with the necessary configurations.

13. Next, we create an auto-scaling group, Note that all these services can be found in the ec2 dashboard.

14. When creating an ASG, it is necessary to create a launch configuration or a launch template (launch configuration in this case) where the following is added: AMI (which becomes a template for new instances to be created for the elastic load balancer), security group (new or existing SG), instance type, and key pair.

15. Add newly created launch configuration to ASG.

16. Choose the default VPC and 2 availability zones.

17. Attach ASG to already existing ELB (created in step 12), and also add a target group.

18. Specify the desired capacity, minimum capacity, and maximum capacity that ASG uses for automatic scaling based on demand.

19. Add email to get notified via an SNS topic whenever an instance is launched in my ASG.

20. Add a name tag (this is optional).

21. An auto-scaling group is created.

22. Using the DNS name of my ELB, my site is visible (best practice).

23. After establishing the fact that it is always best to access my site via the ELB and not from my instance or AMI, I edited the inbound rule for HTTP and HTTPS to allow traffic from the ELB (it was initially set to allow traffic from anywhere).

24. Connecting to my instance via SSH client implies connecting to a machine remotely using the command line (this option was quite tricky, I attempted it several times as I had issues allowing the right inbound rule for SSH).

25. Note that to connect via SSH, I had to navigate to the folder that has my key pair before connecting with my public DNS.

26. I also connected using the EC2 instance connect option, which connects automatically to your ec2 instance on a browser.

27. In this method, a temporary SSH key is uploaded to the ec2 instance.

28. After this hands-on, I cleaned up by terminating my instance(s), deleting my ELB, and detaching my ASG (to avoid actively having some running instances).

I learned the following:

• Each time my auto-scaling group is active, and I terminate any instance(s), based on the desired capacity I specified, it always spins up two instances (such as in the diagram below).

• Each time an instance is stopped and restarted, the public IP changes.

• An instance always takes more time to become active than one created from an AMI (a template) because, most times, the instance built from scratch without an AMI has to download some packages compared to an AMI, which is a template for a new instance.

• For SSH, if you are not on the same network with AWS, it will be difficult to set an inbound rule to my IP except if a VPN is used, I set my inbound rule for SSH using custom as the source.

Conclusion

This tutorial shows how to:

• Attach an auto-scaling group to an elastic load balancer

• Connect an EC2 instance using SSH connect and instance connect options.

Thank you for reading, do well to follow me on Twitter and LinkedIn.