EC2 Auto Scaling

Posted on February 2, 2020 | by Ozzy Brightrose | Leave a Comment

What is EC2 Auto Scaling?

It is the process which enables users to scale their Amazon EC2 instances up or down automatically as per the instructions set by the user. The users set parameters such as minimum and maximum number of instances. Through this feature, the number of Amazon EC2 instances the user is utilizing will increase automatically while the demand is rising in order to maintain performance, and decreases automatically while the demand is decreasing in order to minimize the cost. It’s specifically efficient for applications that shift on hourly, daily or weekly usage. This feature is enabled by Amazon CloudWatch and is available for free. AWS CloudWatch may be referred to for measuring network traffic, CPU utilization, etc.

What is Elastic Load Balancing?

It has a job of automatically distributing incoming request traffic over multiple EC2 instances in aims of achieving higher fault tolerance. It has the ability of detecting wrong instances and automatically rerouting traffic to fit instances till the wrong instances get finally restored in a round-robin process. Learn more about EC2 auto scaling basics

What does Elastic Load Balancing consist of?

Control Service

The ability to automatically scale handling capacity as a reaction to incoming traffic by simply adding and removing load balancers just as needed.

SSL Termination

SSL termination saves important CPU cycles, encoding and decoding SSL within your EC2 instances attached to the ELB. SSL connection in the EC2 instance is not necessary and can easily be removed.

Load Balancer

To monitor and handle incoming requests through the Internet and send them to EC2 instances that are registered with it.

What are the Features of Elastic Load Balancing?

Load Balancers can be added or removed as needed, without even making any alterations to the overall flow of information.
ELS is created to take care of ongoing requests per second while slowly increasing the load pattern.
It is not created to take care of sudden increase in requests like online quizzes, online sales, etc.
EC2 instances and load balancers can be configured so as to accept traffic.
Elastic Load Balancing can be enabled by clients within a single Availability Zone or over a variety of zones to get extra consistent application performance.

1. Open Amazon EC2 console through this link − https://console.aws.amazon.com/ec2/.
2. Choose your load balancer region from the region menu found on the right.
3. Click on Load Balancers from the navigation pane and select Create Load Balancer option. You’ll notice a pop-up window open where you need to provide the necessary details.

1. Inside the load Balancer name box: Type the name of your load balancer.
2. Inside create LB inside box: Choose the exact network you previously selected for instances.
3. Choose Enable advanced VPC configuration, if the selected VPC is default.
4. Click on the Add button and you’ll notice a new pop-up appear for you to choose subnets from the list of available subnets. Choose only a single subnet per availability zone. This window cannot appear without selecting Enable advanced VPC configuration.

1. Select Next, and a pop-up window will appear. When done with choosing a VPC as your network, assign security groups to Load Balancers.
2. Abide by the instructions to assign security groups to load balancers and click on Next.
3. You’ll see that a new pop-up will open with health checkup configuration details of default values. You can set values on your own, yet these are optional. Click Next: Add EC2 Instances.

1. Again, you’ll see a pop-up window will open but with information about instances like registered instances, add instances to load balancers by choosing ADD EC2 Instance option and fill in the necessary information. Click on Add Tags.

Adding tags to your load balancer is not obligatory, but in order to do so, you need to click on the Add Tags Page and type in the details such as key, value to the tag. Once done, select Create Tag option. Click on Review and Create button.
You’ll notice that a review page opens where you can verify the setting. You can also alter the settings by selecting the edit link.

Click on Create to get your load balancer created and then click on Close button.

How is a Load Balancer Deleted?

First: Open the Amazon EC2 console through this link: − https://console.aws.amazon.com/ec2/.
Second: Select Load Balancers option found on the navigation pane.
Third: Choose Load balancer and click on the Action button.
Fourth: Click on the Delete button, and you’ll notice an alert window appear, then click on the Yes, Delete button.

The basics of AWS EC2 Auto Scaling

Posted on January 30, 2020 | by Ozzy Brightrose | Leave a Comment

How AWS EC2 Auto Scaling works?

AWS EC2 auto scaling encapsulates the difference between the public cloud and old-school data centers. With AWS EC2 auto scaling, you can ensure that there is an exact match between demand and supply, in other words, that nothing is wasted. This is a massive contrast to old-school data centers, which had to be built to cope with maximum demand even if this means that most of the capacity is sitting idle most of the time.

AWS EC2 auto scaling is based on defined groups

In keeping with the principle of creating failure-proof architecture, most processes are now served by multiple instances (with similar, or even identical, characteristics) instead of one, robust instance. These instances can be collected into a single EC2 auto scaling group so that they are managed coherently.

AWS EC2 auto scaling monitors the health of all instances in an auto scaling group

In order to ensure optimal performance, auto scaling performs regular health-checks on all the instances in any given AWS EC2 auto scaling group. If it identifies that an instance is unhealthy, it automatically schedules that instance to be replaced by a new instance.

AWS EC2 auto scaling is free

The AWS EC2 auto scaling service itself is free to use. Obviously you pay for any extra AWS EC2 instances it spins up on your behalf, but then you stop paying when it shuts them down.

Setting up an AWS EC2 auto scaling group

There are currently four ways to apply auto scaling to any given AWS EC2 auto scaling group.

Manual – You modify the desired instance capacity and the instance count is updated accordingly.

Scheduled – You can schedule according to time, day of the week or date. This option is typically used for predictable workloads. For example, if an office works 9-5 Monday to Friday, then the vast bulk of its capacity is going to be needed during this time and hence it can be literally scaled-down outside of these hours.

Dynamic – Dynamic scheduling is really taking advantage of the cloud’s capabilities. Essentially you set policies that define how your instances should be auto-scaled and you leave the cloud to manage the actual work.

Predictive – This option forecasts what capacity you are going to need and proactively schedules capacity to be available when it is needed (or canceled when it is not). You can either use the forecasts to manage manual or scheduled auto scaling (Forecast only) or combine predictive auto scaling with dynamic auto scaling (Forecast and scale) and basically have AWS EC2 manage everything for you (although, as always, it’s a good idea to double-check its effectiveness periodically).

At the risk of stating the obvious, the effectiveness of predictive scaling will depend largely on the predictability of your behavior. Predictive auto scaling is backed by effective Amazon Machine Learning modules, which are now capable of performing a very robust analysis of your daily and weekly usage patterns, but that will be of little help if your usage patterns are continually changing.

Dynamic scaling policies

If you want to use dynamic scaling then you need to set the conditions under which it will operate. In addition to the sort of parameters you would probably expect, such as CPU, memory and network utilization, SQS queue size and number of sessions, you can also define custom parameters to suit your particular field of operation.

For example, let’s say you run a website for a fast-food outlet, which has a takeout service. You know most of your customers are local and that when the weather is good, they will generally come down to the restaurant themselves and either eat in or pick up their food to take out. On the other hand, as soon as the weather turns bad, they go online and order delivery. You could therefore integrate with a weather-forecast platform to update capacity in line with the latest weather predictions.

Scaling policy type

Once you have defined your scaling policy, you will need to define a type for it. The main options are:

ChangeInCapacity – you specify the exact number of instances to spin up or down each time there is an auto scaling incident.

ExactCapacity – you set a target instance count and auto scaling will aim to match it.

PercentageChangeInCapacity – you specify the percentage by which to change the number of instances attached to an auto scaling group.

Load balancing

Once you have your AWS EC2 auto scaling group set up to your liking, your last task is to connect it to a load balancer. If you enable Auto Scaling with Elastic Load Balancing, then any instances spun up by AWS EC2 auto scaling will be automatically registered with the load balancer and likewise any instances shut down by AWS EC2 auto scaling will be automatically deregistered. While the instances are running, the load balancer will manage the traffic between them.

read about AWS EC2 spot instances

Understanding AWS EC2 Spot Instances

Posted on January 29, 2020 | by Ozzy Brightrose | Leave a Comment

AWS EC2 spot instances can be rather overlooked in preference to reserved instances. While it’s true that reserved instances are often the core of AWS EC2 cost optimization, spot instances can offer even bigger discounts. This means that it typically makes sense at least to look at the possibilities they offer.

AWS EC2 reserved instances versus spot instances

As a quick refresher, AWS EC2 reserved instances, as their name suggests, are bundles of instances which are sold at a discounted price compared to on-demand usage. The size of the discount depends on various factors including the length of the commitment, whether or not you pay upfront and the degree of flexibility to make changes. At present, the maximum saving is 75%.

AWS EC2 spot instances by contrast are what AWS uses to monetize spare capacity. As such their availability is unpredictable and they can be canceled with two minutes of notice. Basically interruptions happen when demand goes up and AWS can get more money from another user for the instance capacity. On the plus side, however, spot instances can offer savings of up to 90% as compared to on-demand usage.

For the sake of completeness, your spot instance usage is entirely separate from your reserved instance usage. In other words, you’re billed for one or the other, not both at the same time. If you’re using reserved instances and spot instances for the same instance type, your reserved instance will apply unless the conditions for your spot instance are met and then you will switch over. If your spot instance is interrupted, you will switch back to your reserved instance.

Submitting a spot instance request

The process for submitting a spot-instance request is fairly similar to the process for submitting a reserved-instance request. There are, however, a few differences, which reflect the different nature of the service. In particular, you have to specify the maximum price you are willing to pay per instance-hour and whether the request is one-time or persistent. If the latter you also need to specify the period for which the request is valid.

Pro tip, AWS provides a 30-day history of spot prices. This can give you a very good idea of what kinds of discounts you can realistically achieve.

The spot-request lifecycle

Once you have placed your spot request, it will be fulfilled when capacity becomes available at or below the maximum price you have specified. It will continue to be available until either the price is raised so that it goes above your budget or AWS runs out of capacity.

At that point, one-time spot instances will be canceled, but persistent spot instances will be resubmitted and will be reactivated as and when (and if) the necessary criteria are met again.

The significance of region

As with just about everything AWS, there are regional differences in the availability and hence pricing and stability of spot instances. In some regions there is often quite a bit of spare capacity and therefore spot instances are often made available at very low prices and can run for extended periods without interruption. In other regions, spot instances tend to be fewer, further between and more liable to interruption.

AWS provides statistics on interruptions for each spot instance type, instance size, region and operating system. These can be a handy reference when managing your spot usage.

Spot instances and stability

Obviously, you are probably never going to use spot instances for a mission-critical application, which has to be kept running at all times. You can, however, use them for applications that benefit from a high degree of stability. You just need to create your architecture so that it can withstand failure. In principle, you should be doing this as much as you can in any case and in any environment. In practice, there may well be room for improvement here, especially if you’ve just performed a “lift and shift” migration to the public cloud.

Understanding the concept of creating failure-proof architecture

Rather appropriately, the basic concepts behind the creation of failure-proof architecture are actually quite similar to the concepts behind the creation (and adoption) of the public cloud. Basically you deconstruct and hence, effectively, decentralize. In other words, you have to get out of the mindset of creating one robust instance per service and into the mindset of creating multiple smaller instances per service. That way you don’t need to worry about keeping a service running constantly, because a single failure will be a blip rather than a catastrophe.

Defined-duration spot instances

There is a bit of a twist on the concept of spot instances and it is that AWS offers the option of using spot instances for a fixed duration of up to 6 hours at a fixed (and discounted) price and with a guarantee of service, in other words, with no risk of interruption. These can be great for when you have workloads which allow for flexible scheduling, but are of a predictable duration.

aws ec2 pricing

Understanding AWS EC2 Reserved Instances

Posted on January 28, 2020 | by Ozzy Brightrose | Leave a Comment

Many people may already be aware that AWS EC2 reserved instances are important for AWS cost optimization. To get the most out of them, however, you need to have a more in-depth understanding of how they actually work.

The basics of AWS EC2 reserved instances

Reserved instances are essentially bundles of services purchased in advance for a discount. This can be anything up to 75% on the on-demand price. Reserved instances are issued for periods of either 12 or 36 months on a “use-it-or-lose-it” basis. In other words, there is no option to roll-over any unused capacity.

Understanding AWS EC2 payment options

Although we described reserved instances as being “purchased in advance”, there is actually a bit of nuance here. Basically, once you commit to a reserved instance, you have to pay for it, but you have three different ways to do so (Calculate EC2 reserved instances).

Full upfront payment – This option will generally get you the biggest discount, but it may not do wonders for your cash flow.

Partial upfront payment – This option will often get you a smaller discount, but it can make it easier to find the funds to make the down payment. You then have to budget for ongoing usage but at a discounted rate.

No upfront payment – This option typically gets you the lowest discount, but it can make it much easier to manage your cash flow. You just have to budget for ongoing usage at a discounted rate.

For the sake of completeness, your billing is based on hourly usage, however, the degree of exactness with which your hourly usage is calculated will depend on various factors, particularly which operating system you use. With Linux/Unix instances usage is calculated to the second, whereas with Windows instances it is rounded up to the nearest hour.

Setting the reservation terms

The reservation terms determine the instance(s) to which the discount will be applied. It’s really important to think carefully about your usage patterns so you can get the very best value out of reserved instances.

For example, let’s say your workload consists of about 80% regular, predictable tasks and 20% irregular tasks, for which there is a bit of flexibility. In this situation, it will probably make the most sense to use reserved instances for your regular tasks and undertake the flexible tasks when you can buy spot instances.

Understanding the concept of offering class

Reserved instances come in two basic forms, standard and convertible. Standard reserved instances only offer a very small degree of flexibility to change the terms of the reserved instance. For example, you might be able to change the size of an instance but not the instance type. Convertible reserved instances can be exchanged against other convertible reserved instances and thus give you much more scope to alter your reservation terms. For example, you can update the instance type, scope and tenancy form.

Please note, however, that this flexibility comes at a price. Convertible reserved instances typically offer smaller discounts than standard reserved instances. Please also note that you cannot use this system to get a “back-door refund” of a reserved instance by exchanging your existing reserved instance a lower-priced option. You will, however, have to pay the difference if you opt for a more expensive option.

The basics of reservation terms

Most of the factors involved in the reservation terms are fairly self-explanatory. Choosing the right one for you will therefore essentially depend on you taking the time to analyze your usage effectively so that you pick the right option for your needs. There is, however, one specific factor that is worth a closer look.

Region versus availability zone

Anyone familiar with AWS will probably be only too familiar with the importance of choosing the right region. This certainly applies to AWS EC2 instances in general. With AWS EC2 reserved instances, however, there is a bit of an extra twist. This is that you can choose between a reserved instance for a given region or a reserved instance for one or more selected availability zones within a region.

The benefits of regional reserved instances

Probably the most obvious benefit of regional reserved instances is that you have the flexibility to apply them to any availability zone you choose. What may be less obvious is that this can also give you more flexibility with instance sizing. Basically, if you buy a regional reserved instance of a Linux or Unix instance type, the reserved instance can be applied to any size of instance within that type.

The benefits of availability zone reserved instances

If you opt to buy an availability zone reserved instance, then you are basically giving up flexibility for security. Specifically, Amazon will give you a guarantee that they will supply the reserved capacity at any given time. This means that availability zone reserved instances may be the best option for occasions when you just cannot risk your EC2 instance being unavailable.

what factors effect ec2 pricing

Factors that Influence Your AWS EC2 Pricing

Posted on January 27, 2020 | by Ozzy Brightrose

AWS EC2 pricing is influenced by a large number of factors. Some of these may be well-known, e.g. your choice of region. Others may come as more of a surprise or just not be properly understood.

The factors that influence AWS EC2 pricing

The key factors that influence AWS EC2 pricing are as follows:

Region
Purchasing options
Usage duration
Instance size
AWS Instance type and generation
Processor, processor optimization and use of bursts
Use of elastic graphics and elastic inference
Software stack
Tenancy type

Region

The choice of region is a huge factor in Amazon’s pricing structure. It may not be the only factor in your choice of region. In fact, these days, your choice of region may be dictated by the law rather than by your budget preferences. If possible, however, it should certainly be factored into your decision-making process.

Purchasing options

Basically, you want to do everything you can to use reserved instances and spot instances rather than on-demand pricing. Be aware that on-demand capacity reservations have nothing to do with reserved instances. They are just a way to ensure that specific functions have guaranteed access to resources as, when and if they need it. These are charged at on-demand prices and, as such, are best avoided.

Usage duration

In itself, this is self-explanatory. What may not be so obvious, however, is that the granularity with which usage duration is calculated can vary widely. For example, if you use a Linux EC2 instance, it is per second, whereas with Windows EC2 instances, it is per hour. This means that if you use a Linux instance for one hour and one second, you are billed for one hour and one second. If you use a Windows instance for one hour and one second, you are billed for two hours.

Instance size

This really is pretty self-explanatory. The larger the instance, the more resources you get (e.g. vCPU, memory and storage) and the more you pay. If you actually look at a table showing AWS pricing, the correlation is fairly obvious.

Instance type and generation

The fact that different instance types have different prices is probably both obvious and logical. What may be less obvious is the fact that it can be very useful to compare more expensive instance types with enhanced versions of more affordable instance types. For example, comparing graphics-optimized instances with general-purpose instances boosted with elastic graphics.

Pricing for different generations of the same instance type may be the exact opposite of what you expect. In many industries, companies cut the prices of the older generations of a product or service to encourage people to use it up so it maximizes its return on investment before it moves on.

AWS EC2, however, does the exact opposite. It wants to encourage people to move onto the newer, more efficient generations of instances, so it makes the older ones more expensive.

Processor, processor optimization and use of bursts

While it may seem tedious, it really can pay to make an effort to analyze the value for money offered by the different processors available both across instances and within instance types. As before, you also want to compare more expensive processors with more affordable processors and the use of processor optimization and/or bursts.

Use of elastic graphics and elastic inference

Elastic graphics is a way to boost the graphics performance of non-graphics-optimized instances and elastic inference can be used to boost the floating-point-calculation performance of non-compute-optimized instances. As previously mentioned, it’s very much recommended to compare the value offered by using optimized instance types with the value offered by using more affordable instance types.

Software stack

Software stack basically means operating system and database (if relevant). Basically, Linux-based operating systems are priced more affordably than Windows. That’s in addition to the fact using a Linux-based operating system means that your usage is calculated per second rather than per hour.

At present, the only database available in AWS EC2 is Microsoft SQL (Web, Standard or Enterprise) but you can put this on top of a Linux distro and pay less than you would if you had put it on top of Windows.

Tenancy type

AWS has an interesting system in which it essentially works as a public cloud and a private cloud. Not only that, but you can choose between a private cloud with virtualization software to divide the physical server between different EC2 dedicated instances and a private cloud without virtualization software, just “pure” cloud infrastructure.

As you would expect, the shared resources of the public cloud infrastructure are priced more affordably than either the EC2 dedicated host infrastructure (virtualized) or the EC2 “bare metal” infrastructure (non-virtualized).

For practical purposes, however, this is probably going to be irrelevant since most people will only use either of these options because they have to either for legal reasons or for practical ones.

Optimizing Your AWS EC2 Instances

Posted on January 23, 2020 | by Ozzy Brightrose | Leave a Comment

EC2 instances are already grouped into five basic types, which are optimized for different purposes. These can, however, be further refined through customization options.

A quick refresher of AWS EC2 instance types

AWS EC2 instance types are grouped into five “families”. These are:

General purpose – A, M and T
Compute optimized – C
Memory optimized – R, U, X and Z
Storage optimized – D, H and I
Accelerated computing – F, G and P

The names of each instance type follow this naming convention:

Instance type, instance generation, (additional capabilities).size. For example c5d.large

The extended capabilities currently include
A AMD EPYC processors
D NVMe-based SSD disk space
E Extended memory
N Enhanced networking (up to 100Gbps)
S Smaller amounts of vCPU and memory

The exceptions to this rule are the Bare Metal U and I instances.

Optimizing AWS EC2 instances for vCPU

This is exactly what it sounds like. You can adjust the default number of vCPUs and turn hyperthreading on and off.

Optimizing AWS EC2 instances for graphics with the Elastic Graphics Accelerator

Strictly speaking, if you really want to optimize AWS EC2 instances for graphics then you should choose one of the “G” options, which have been specifically created for that purpose. On the other hand, the G instances are some of the most expensive AWS EC2 instance types and, understandably, people might grudge paying for them if they don’t really need all that graphics acceleration power.

You can split the difference by adding using the Elastic Graphics Accelerator to add up to 8Gb of graphics memory to a wide range of EC2 instance types (note you do not get the benefit of the full graphics card as you do with the G instance types). You need to do this when an instance is opened (in other words, you can’t add the Elastic Graphics Accelerator to an instance which is already running) and the Elastic Graphics Accelerator is automatically terminated along with the instance.

You can only use the Elastic Graphics Accelerator once per instance, but frankly if you were thinking about using the Elastic Graphics Accelerator more than once, you should probably be paying for a proper G instance in any case.

Optimizing AWS EC2 instances for throughput with Elastic Inference

The “P” instances are optimized for GPU-intensive computing, but again, they are far from the most budget-friendly instances AWS has to offer. You therefore typically want to limit them to when they are really needed and reach for Elastic Inference when they are not.

Generally speaking, if you’re running machine-learning training, then you’re probably going to need to pay up for a proper “P” instance type. If, however, you’re just running a machine-learning trained module for making predictions, then you’re probably going to have fewer inputs and hence need less GPU power. You are therefore more likely to be able to get away with using Elastic Inference to boost the GPU power of “standard” EC2 instances.

As with the Elastic Graphics Accelerator, you need to activate Elastic Inference when you open a new instance (in other words, you cannot add Elastic Inference to an instance which is already running) and the Elastic Inference automatically terminates when the instance is closed.

Also as with the Elastic Graphics Accelerator, you can only apply Elastic Inference once per instance. This is a bit of a shame as Elastic Inference ranges from 1 to 32 trillion floating-point operations per second, whereas P3 instances currently start at 125 trillion floating-point operations per second, so it would have been nice to have been able to scale up a bit more before paying up for a proper P instance. Even as it stands, however, you still have quite a bit of flexibility to increase the GPU power at a reasonable cost.

Optimizing for privacy with dedicated resources

AWS has an interesting set up in that it is a public cloud that can essentially do double duty as a private cloud by allowing users to assign themselves dedicated resources. You may already be aware of EC2 Dedicated Host. This is when a physical server is entirely dedicated to one AWS account and virtualization software is then used to divide the server’s resources into AWS EC2 dedicated instances. This approach is often used in Bring Your Own Licence scenarios and also for organizations that need sole use of servers to satisfy compliance requirements.

You may not, however, be aware that AWS also offers EC2 Bare Metal. This is essentially the same idea, except that with AWS EC2 Bare Metal, there is no virtualization software used. In other words, you get “pure” cloud infrastructure. This means that you can use them for applications that need non-virtualized environments, typically either for licensing reasons or because you need to squeeze the absolute maximum possible performance out of each server.