Skip to main content

Auto Scaling in AWS

Auto Scaling
Auto Scaling is a feature in AWS for scaling up or scaling down the number of Amazon EC2 instances.

The Auto Scaling feature can be accessed and configured via the AWS Management Console from the EC2 service page. Auto Scaling can also be configured via the AWS Command Line Interfaces (CLI) or APIs.

Auto Scaling is enabled by CloudWatch and does not carry additional fees. However, there are fees applied to EC2 instance usage and CloudWatch detailed monitoring.

The scenario in which you can use Auto Scaling properly is in which you have an application that can be load balanced. These applications must be able to be dynamically installed or updated after an EC2 instance launch. This would require some sort of scripting e.g. you can use PowerShell Desired State Configuration if you are familiar with it.

You can create your own AMIs (Amazon Machine Image) for every version of your application release, and these AMIs can be used to launch new EC2 instances. In this way, little or no scripting is required to have identical applications on multiple application servers.

Launch Configuration
Auto Scaling is configured by firstly creating a Launch Configuration. You specify a name for this configuration and the AMIs to use for launching EC2 instances along with basic network, storage and security group configurations .

AutoScaling Group
Create an Auto Scaling group for this Launch Configuration. You will need to configure basic network configurations and scaling policies based on CloudWatch alarms that were created. You also (optionally) should specify a load balancer. You can configure Notifications so an administrator gets informed when an instance gets created or terminated or failed to launch or failed to terminate by Auto Scaling.

It should be obvious now that with some careful planning and design of your application, you can make it highly available through the use of load balancers and make it run at maximum performance by launching more application servers when needed and then terminating the servers during off peak or idle periods.

More information on using Auto Scaling is here:

https://aws.amazon.com/autoscaling/getting-started/

My blog on Amazon CloudWatch :

http://networkadministratorsurvivalkit.blogspot.com/2016/08/aws-cloudwatch.html

Labels:

Comments

Post a Comment

Popular posts from this blog

How To Migrate Mailboxes from Exchange 2010 to Exchange 2016 using PowerShell

The Scenario

Your organisation have decided to migrate from Exchange 2010 to Exchange 2016. The Exchange 2016 server have been installed into your current Exchange Organization. The Mailbox role have been installed on the Exchange 2016 server and you are ready to start moving mailboxes from the Exchange 2010 server to the Exchange 2016 server.

Migrating a Mailbox from Exchange 2010 to Exchange 2016

Using New-MoveRequest

 Migrating a single mailbox involves invoking the cmdlet New-MoveRequest from the Exchange Management Shell on the Exchange 2016 server. Make sure that your user account that you have logged into the server with have the Organization Management role.

The common parameters that I use for the New-MoveRequest cmdlet is :

New-MoveRequest -Identity 'useralias@somedomain.com' -TargetDatabase "DB02" -BadItemLimit 10

The -Identity parameter identifies the mailbox to be migrated. I usually use the e-mail address of the mailbox for the identity since it's uniqu…
Post a Comment
Read more

How to Schedule an Exchange PowerShell Script in Task Scheduler

Exchange Management Shell
Since Exchange 2007, Microsoft has provided the Exchange Management Shell so administrators can manage all aspects of the Exchange server from the command line.



The Exchange Management Shell has Exchange specific PowerShell cmdlets. These Exchange cmdlets are not normally available in an ordinary PowerShell command environment.



An example of what can be done in the Exchange Management Shell is to run a PowerShell script to list all the mailboxes on the Exchange server to a file. You can output columns based on display name, size of the mailbox, last logon, and other available mailbox attributes.

You can also schedule a batch migration of mailboxes from one database to another such as the migration of mailboxes from Exchange 2010 to Exchange 2013.

Scheduling the PowerShell Script

Once you have written a PowerShell script and utilised the Exchange cmdlets, you can run it with no problems inside the Exchange Management Shell. If you were to try to run it under a …
Post a Comment
Read more

Getting a List of Installed Applications on Local and Remote Computers

Introduction

A few months ago, I was asked to have a look at a PowerShell script which was supposed to be able to list installed applications on the local and remote Windows computers on the network.

The script was from the Microsoft Gallery site.

Here is the original script, with explanations of what it's supposed to do.

https://gallery.technet.microsoft.com/scriptcenter/Get-a-List-of-Installed-c47393ed/view/Discussions

Unfortunately if you run the script, it will only list the applications installed on the local PC but outputs the same results for all the computers that you are trying to inventory.

I found that the program was very well structured so perhaps the author did this on purpose. Anyhow, I modified the Function FindInstalledApplicationInfo($ComputerName)
and used .NET's remote registry functions in place of the original PowerShell registry functions which looks at the local registry only. In this way, the .NET's remote registry functions can look at the local re…
Post a Comment
Read more