Amazon Web Services: Reserved Instances DeMystifed


Amazon Web Services offer a credible and cost effective alternative to on premise infrastructure.

This is especially true where demand is spikey or unpredictable. The consumption model is perfect for these scenarios.

However most other cloud providers offer the ability to buy resources as a commitment (or subscription) thus reducing the cost. It’s the cloud bulk buy.

In AWS this is call a Reserved Instance, you can purchase a reserved instance (RI) at a lower cost than the consumption equivalent.


What Savings are Available

You can buy RI’s in 3 ways :-

No Upfront – this means no CapEx but is also the lowest saving. You will pay for the resource hourly but at a lower rate due to the commitment. This will typically save you around 30%

Partial Upfront – this is effectively a compromise there is some CapEx and a substantially lower hourly cost. Again there is a time commitment. Typically this will save 50%

Fully Upfront – all of the cost is payed for upfront with no hourly charges, this represents the largest saving. This will typically give a saving of around 55%.


How Do I Buy RI’s

An RI is a machine instance and is purchased through your normal route.

You buy an RI of the required size and type. The RI will automatically be allocated to a running instance that matches so your savings will be instant.

What can I do with my RI?

Once you have an RI, depending on the type, you can split or combine them to better fit your requirements and maximise the benefit. They can also be moved between Availability Zones.

Linux Split/Combine Move
Redhat Move
Windows Move


Splitting and combination can only be done with instances in the same family, so a T2 instance cannot be combined with a M4 instance.

Each instance type within a family has a points value and you can split an instance in to smaller parts as long as the total point stay the same.

  • WARNING: This takes at least a little planning due to the above. Randomly splitting instances could easily leave you with instances that are two small to be of use.

If you no longer require a RI it can be sold on the RI marketplace. To do this you will need to have a bank account registered as payment is taken in cash (where applicable). Once sold you are no longer responsible for the RI or its associated costs.

Most RI’s are sold at MSRP but the price is determined by the seller. Of course you can also buy an RI this way.


Tagged with: ,

Disaster Recovery for End User Desktops

My Apology


Firstly let me apologise for the shameless plugs I will make, I work as technical presales and as such have a reasonably good knowledge of a small set of products and selling them puts the bread (my friends will know the irony of this statement) on the table. SO my solutions will always be built on theses products.

The fortunate thing about my situation is that the products I sell and use are the best on the market so I have no hesitation in recommending them.


The Problem

I have been asked several times recently about how to us VMware SRM to protect desktops in a VDI environment.

My answer is always the same. If you need to recover the desktop then you are doing it all wrong. In this post I will go in to how DR of a desktop environment can be achieved in a painless and efficient way.


Non Persistence

The key to all this is also the biggest liberator of the desktop environment namely Persistence. To be more precise the lack of it.

When you fully separate the key functions of a desktop you free it from the shackles of persistence and allow it to wander through the world of virtualisation un hindered.

Back to reality. What I mean is a desktop has three main layer (a virtual one leastwise) App and Data, Persona and OS.

In many cases when I talk to customers they are not aware that we have the ability to do things differently in a VDI deployment.

App/Data – Many of todays apps are web based so they have been freed already. Legacy apps can be virtualised, remoted or (in my opinion the best and kindest way) replaced.

Persona – VMware Horizon has built in persona management that allows us to take all that personal customisation and information out of the desktop itself. There are also some excellent third party tools such as ProfileUnity from LiquidWare Labs that will do an excellent job of helping us in our journey to VDI Nirvana.

OS – This is what VDI is here for to deliver the OS and if we are just delivering the OS on a virtual desktop we really start to realise the benefits, namely that we can create or destroy the desktop at will because there is nothing except the s in the VDI image that we care about.


Leveraging VMware Horizon for Desktop DR

Horizon’s VDI component (the software previously known as View) has some built in resilience features that lend themselves to giving us a disaster proof (well resistant so as not to tempt fate) solution.

The connection broker can be part of a group, we can have replicas as part of the base configuration. So at the most basic level we have the resilience we require out of the box.

We have two basic ways to deploy this in a DR scenario :-

Active – Active

In the active-active scenario we will have connection brokers at both sites ( assuming a two site setup) serving requests.

In the event of a failure the working site simply continues to service the requests.

Ok I glossed over the networking, we would need some load balancing in the equation, something like an F5 appliance would do the job and its Horizon savvy. More about this in a later post.

Active – Passive

So less complex (potentially from a network perspective), but just as efficacious. The secondary site is on standby with the desktop pools set up but not enabled. In the event of a failure we enable said pools, do some manual DNS changes and hey presto.

In both these scenarios the users get disconnected from there desktop. When they try and reconnect they simply login and get a new one from the new pool.

Horizon 6 has enhanced these abilities with its Cloud Pod architecture making this DR design just that bit simpler.


Protecting the ‘Other Stuff’

These designs (well overviews) all require that the persistent stuff (stuff is a well know technical term) is replicated and protected. This is where SRM is a very useful tool.

In almost all cases we will need to recover production applications, indeed that’s why we are recovering the desktops, so make these servers part of that recovery.

Identity servers (AD or similar) will usually be protected using the built in mechanisms, this may also be true of Mail, DNS and DHCP but theses can be protected using server recovery mechanisms.

Tagged with: , , ,

Virtual SE Blog

Hello all.

I am a virtualisation SE working with various technologies in the VMware ecosystem.

My am is to help customers and partners with some of the common issues I see in the market place.

My speciality is VMware so this will always feature heavily in the articles i write (they pay the bills), I do however believe whole heartedly in the technologies i write about.

With this in mind feel free to comment on my posts.