Skip to main content

Amazon EC2

EC2 stands for Elastic Compute Cloud. It is the equivalent of a virtual machine. A virtual machine in AWS is known as an EC2 instance.

Here is an excerpt of the EC2 features:

  •       Virtual computing environments, known as instances
  •        Preconfigured templates for your instances, known as Amazon Machine Images (AMIs), that package the bits you need for your server (including the operating system and additional software)
  •       Various configurations of CPU, memory, storage, and networking capacity for your instances, known as instance types
  •       Secure login information for your instances using key pairs (AWS stores the public key, and you store the private key in a secure place)
  •       Storage volumes for temporary data that's deleted when you stop or terminate your instance, known as instance store volumes
  •       Persistent storage volumes for your data using Amazon Elastic Block Store (Amazon EBS), known as Amazon EBS volumes
  •       Multiple physical locations for your resources, such as instances and Amazon EBS volumes, known as regions and Availability Zones
  •       A firewall that enables you to specify the protocols, ports, and source IP ranges that can reach your instances using security groups
  •       Static IP addresses for dynamic cloud computing, known as Elastic IP addresses
  •       Metadata, known as tags, that you can create and assign to your Amazon EC2 resources
  •       Virtual networks you can create that are logically isolated from the rest of the AWS cloud, and that you can optionally connect to your own network, known as virtual private clouds (VPCs)


AWS Reserved Instances

Whenever a new EC2 instance is created, it is an on-demand instance. What this means is, you are charged according to the uptime of this instance on an hourly rate. If you turn the instance off, there will be no charge.

AWS allows you to purchase reserved instances whereby you nominate an instance type (i.e. compute capacity), region or availability zone. Once you reserve an instance, you start paying for the instance at a lower rate for the reservation period.

There are three payment options when purchasing a reserve instance. The three payment options are:

  • No Upfront Payment
  • Partial Upfront Payment
  • Full Upfront Payment


More information on the payment options can be found on the following link:



You can apply the reserved instances to running EC2 instances which match the type, region and availability zone or the type and region. However, if you were to stop the running EC2 instances, you would still continue paying for the reserved instances. You would use reserved instances for applications and services that are needed to be running 24 x 7. You can also launch on-demand instances and make use of the Reservation Instance benefits if the type and region or type and availability zone of the reserved instance matches.

The reserved instance period does not automatically renew when it expires, so you have to be mindful of when a reserved instance expires and renew it again. If a reservation instance period is not renewed, the running EC2 instances which had the reservation instance benefits applied would then be charged at the normal on-demand hourly rate.


More information on reserved instances can be found in the following link:



Spot Instances

AWS allows you to make a bid on unused EC2 instances. When the value of an unused EC2 instance matches the bid, it will then launch. This is a good way to save money and you are not concerned about when the instances will launch. You might use this in a situation where you already have a certain number of reserved instances running, and if the “price is right”, you want the additional instances to launch to take some of the load of the reserved instances.

Amazon EC2 can terminate the Spot instances that are launched if the hourly rate or the availability of Spot instances changes.

Why are there unused EC2 instances in AWS? By design, each physical host can only launch particular instance types. Depending on the instance type, there can only be a certain number of instances that can be launched on that host. There may be situations where not all available instances have been launched. These are available to be used as Spot instances, and AWS EC2 will make it unavailable again if the EC2 instances are required to be launched as an on-demand or reserved instance. It will terminate the running Spot instance automatically.

What this means is that if you are planning to use Spot instances to save costs, you better make sure your running application can handle a shutdown.

More information on Spot Instances can be found in this link:



There were some questions in the test exam to do with on-demand instances, reserved instances, and spot instances.

They also asked questions related to the Light, Medium, and Heavy Utilization Reserved Instances in the practice exam. However, the Light, Medium, and Heavy Utilization Reserved Instances are no longer available for purchase.

Hopefully the real exam doesn’t have questions related to them.

Comments

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…

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 …

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…