Skip to main content

Elastic IP Addresses in AWS

Elastic IP addresses are static Public IP addresses that are allocated to AWS Accounts.You can associate it to an EC2 instance or network interface. You need to manually allocate an Elastic IP address to your account. They are not automatically assigned. By default, you can allocate up to 5 Elastic IP addresses. To allocate more, you need to submit a request to AWS.

An Elastic IP Address can easily be disassociated from an EC2 instance or network interface and re-associated with another instance or interface. However, if you were to release it from your account, it would go back to the pool of public IP addresses in AWS that can be assigned to other AWS accounts. There is no guarantee that if you were to allocate a new IP address to your account you would get the same one you had previously. BE CAREFUL and do not just release IP addresses because you are not using them. Disassociating from EC2 instances and network interfaces is fine to do as the Elastic IP addresses still remain in your account.

What makes Elastic IP addresses useful in high availability design is that these IP addresses can be associated to or disassociated from EC2 instances or network interfaces. If an EC2 instance is down for whatever reason, the Elastic IP address can be either re-associated with another instance manually via the AWS Management Console or be re-associated programmatically. There is no need to change the DNS host name to re-point to another IP address and wait for DNS changes to propagate through the internet.

You can only associate one Elastic IP address to one EC2 instance or network interface. An Elastic IP address cannot be associated with multiple EC2 instances or network interfaces at one time, and you
cannot have EC2 instances or network interfaces with multiple Elastic IP Addresses.

Elastic IP Addresses vs Dynamically Assigned Public IP Addresses

When launching EC2 instances, there is an option to assign a Public IP address to this instance. This Public IP address is dynamically assigned and associated to THIS EC2 instance only. When it is stopped or terminated, the Public IP address is released. When the instance is started up again, assuming it was only stopped and not terminated, it will get a new dynamically assigned Public IP address. This Public IP address cannot be transferred to another instance. There is probably a use case for this, but I can't think of it at the moment.

If you assign an Elastic IP Address to an instance that already has a dynamic public IP address assigned on launch, this public IP address will be released from this instance. You can then only access this instance via the Elastic IP Address.

It seems to me Elastic IP Addresses are the way to go.

Elastic IP Addresses for EC2 Classic vs Elastic IP Addresses for EC2 VPC

The EC2 Classic is the original release of Amazon EC2. These instances run in a single flat network that is shared with other clients.

The EC2 VPC instance was introduced in 2009 when the Amazon Virtual Private Cloud (VPC) service was released.

If you account supports EC2 Classic, there will be a pool of Elastic IP addresses for use with the EC2 Classic instances and another pool of Elastic IP addresses for use with the EC2 VPC instances. You can't associate Elastic IP addresses from one type of EC2 instance to another. However, you can migrate the Elastic IP addresses for the EC2 Classic instances to the pool for the EC2 VPC instances so that they can be used with the EC2 VPC instances.

Most people won't need to worry about this as the default AWS Account that are created in recent years only support EC2 VPCs. When a new AWS Account is created, there is already a default VPC created for your account. When you launch a new EC2 instance, the default VPC gets selected by default. If you have created additional VPCs in your account, you can select them instead before launching the instance. In this way, EC2 instances are always going to be EC2 VPC instances.

Elastic IP Addresses are Region Specific

Elastic IP Addresses cannot be assigned to instances in other Regions in your account. They are Region specific.


Popular posts from this blog

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

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 '' -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

Elastic Load Balancing in AWS

Elastic Load Balancing is a service which allows for the automatic distribution of incoming traffic across multiple Amazon EC2 instances.These EC2 instances should be in separate availability zones in a particular region.This enables applications to achieve fault tolerance and high availability if they are designed so that they can be accessed from multiple server instances. Sometimes an application may not need to be designed as such if they both point to the same data source. More often than not, these applications can be run from anywhere. They are good candidates to be put behind the Elastic Load Balancing service.It is up to the system or cloud administrator to ensure that identical versions of the application exist across all servers that are going to be load balanced. The Elastic Load Balancing service can be integrated with Auto Scaling in AWS. As more load is put on your application servers, additional EC2 instances can be launched by Auto Scaling.Once the load dissipates. E