25 Best Practice Tips for architecting your Amazon VPC

According to me Amazon VPC is one of the most important feature introduced by AWS. We have been using AWS from 2008 and Amazon VPC from the day it was introduced and i strongly feel the customer adoption towards AWS cloud gained real momentum only after the introduction of VPC into the market. 

Amazon VPC comes with lots of advantages over the limitations faced in Amazon Classic cloud like: Static private IP address , Elastic Network Interfaces :  possible to bind multiple Elastic Network Interfaces to a single instance, Internal Elastic Load Balancers, Advanced Network Access Control ,Setup a secure bastion host , DHCP options , Predictable internal IP ranges , Moving NICs and internal IPs between instances, VPN connectivity, Heightened security etc. Each and everything is a interesting topic on its own and i will be discussing them in detail in future. 

Today i am sharing some of our implementation experience on working with hundreds of Amazon VPC deployments as best practice tips for the AWS user community. You can apply some of the relevant ones in your existing VPC or use these points as part of your migration approach to Amazon VPC.

Please also look into 27 Best practices on AWS Security Groups to understand the relation with Amazon VPC. 
http://harish11g.blogspot.com/2015/06/best-practices-tips-on-amazon-web-services-security-groups-aws-security-managed-services.html

Practice 1) Get your Amazon VPC combination right: Select the right Amazon VPC architecture first.  You need to decide the right Amazon VPC & VPN setup combination based on your current and future requirements. It is tough to modify/re-design the Amazon VPC at later stage, so it is better to design it taking into consideration your NW and expansion needs for next ~2 years. Currently different types of Amazon VPC setups are available; Like Public facing VPC, Public and Private setup VPC, Amazon VPC with Public and Private Subnets and Hardware VPN Access, Amazon VPC with Private Subnets and Hardware VPN Access, Software based VPN access etc. Choose the one which you feel you will be in next 1-2 years.

Practice 2) Choose your CIDR Blocks: While designing your Amazon VPC, the CIDR block should be chosen in consideration with the number of IP addresses needed and whether we are going to establish connectivity with our data center. The allowed block size is between a /28 netmask and /16 netmask. Amazon VPC can have contain from 16 to 65536 IP addresses. Currently Amazon VPC once created can't be modified, so it is best to choose the CIDR block which has more IP addresses usually. Also when you design the Amazon VPC architecture to communicate with the on premise/data center ensure your CIDR range used in Amazon VPC does not overlaps or conflicts with the CIDR blocks in your On premise/Data center. Note: If you are using same CIDR blocks while configuring the customer gateway it may conflict.
E.g., Your VPC CIDR block is 10.0.0.0/16 and if you have 10.0.25.0/24 subnet in a data center the communication from instances in VPC to data center will not happen since the subnet is the part of the VPC CIDR. In order to avoid these consequences it is good to have the IP ranges in different class. Example., Amazon VPC is in 10.0.0.0/16 and data center is in 172.16.0.0/24 series.

Practice 3) Isolate according to your Use case: Create separate Amazon VPC for Development , Staging and Production environment (or) Create one Amazon VPC with Separate Subnets/Security/isolated NW groups for Production , Staging and development. We have observed 60% of the customer preferring the second choice. You chose the right one according to your use case. 

Practice 4) Securing Amazon VPC : If you are running a machine critical workload demanding complex security needs you can secure the Amazon VPC like your on-premise data center or more sometimes. Some of the tips to secure your VPC are: 

• Secure your Amazon VPC using Firewall virtual appliance, Web application firewall available from Amazon Web Services Marketplace. You can use check point, Sophos etc for this
• You can configure Intrusion Prevention or Intrusion Detection virtual appliances and secure the protocols and take preventive/corrective actions in your VPC
• Configure VM encryption tools which encrypts your root and additional EBS volumes. The Key can be stored inside AWS (or) in your Data center outside Amazon Web Services depending on your compliance needs. http://harish11g.blogspot.in/2013/04/understanding-Amazon-Elastic-Block-Store-Securing-EBS-TrendMicro-SecureCloud.html
• Configure Privileged Identity access management solutions on your Amazon VPC to monitor and audit the access of Administrators of your VPC.
• Enable the cloud trail to audit in the VPC environments  ACL policy's. Enable cloud trail : http://harish11g.blogspot.in/2014/01/Integrating-AWS-CloudTrail-with-Splunk-for-managed-services-monitoring-audit-compliance.html
• Apply anti virus for cleansing specific EC2 instances inside VPC. Trend micro has very good product for this.
• Configure Site to Site VPN for securely transferring information between Amazon VPC in different regions or between Amazon VPC to your On premise Data center
• Follow the Security Groups and NW ACL's best practices listed below

Practice 5) Understand Amazon VPC Limits: Always design the VPC subnets in consideration with the expansion in the future. Also understand the Amazon VPC's limits before using the same. AWS has various limitations on the VPC components like Rules per security group, No of route tables and Subnets etc. Some of them may be increased after providing the request to the Amazon support team while few components cannot be increased. Ensure the limitations are not affecting your overall design. Refer URL:
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html

Practice 6) IAM your Amazon VPC: When you are going to assign people to maintain your Amazon VPC you can create Amazon IAM account with the fine grained permissions (or) use Sophisticated Privileged identity Management solutions available on AWS marketplace to IAM your VPC.

Practice 7) Disaster Recovery or Geo Distributed Amazon VPC Setup : When you are designing a Disaster Recovery Setup plan using VPC or expanding to another Amazon VPC region you can follow these simple rules. Create your Production site VPC CIDR : 10.0.0.0/16 and your DR region VPC CIDR:  172.16.0.0/16. Make sure they do not conflict with on premises subnet CIDR block in event both needs to be integrated to on premise DC as well. After CIDR blocks creation , setup a VPC tunnel between regions and to your on premise DC. This will help to replicate your data using private IP’s. 

Practice 8) Use security groups and Network ACLs wisely:  It is advisable to use security groups over Network ACLs inside Amazon VPC wherever applicable for better control. Security groups are applicable on EC2 instance level while network ACL is applicable on Subnet level.  Security groups are used for White list mostly. To blacklist IPs, one can use Network ACLs.

Practice 9) Tier your Security Groups : Create different security groups for different tiers of your infrastructure architecture inside your VPC. If you have Web, App, DB tiers create different security group for each of them. Creating tier wise security groups will increase the infrastructure security inside Amazon VPC.  EC2 instances in each tier can talk only on application specified ports and not at all ports. If you create Amazon VPC security groups for each and every tier/service separately it will be easier to open a port to a particular service. Don't use same security group for multiple tiers of instances, this is a bad practice. 

Example: Open ports for security group instead of IP ranges : For example : People have tendency to open for port 8080 to 10.10.0.0/24 (web layer) range. Instead of that, open port 8080 to web-security-group. This will make sure only web security group instances will be able to contact on port 8080. If someone launches NAT instance with NAT-Security-Group in 10.10.0.0/24, he won't be able to contact on port 8080 as it allows access from only web security group. 

Practice 10 ) Standardize your Security Group Naming conventions : Following a security group naming conventions inside Amazon VPC will improve operations/management for large scale deployments inside VPC. It also avoids manual errors, leaks and saves cost and time overall.

For example: Simple ones like Prod_DMZ_Web_SG or Dev_MGMT_Utility_SG (or) complex coded ones for large scale deployments like

USVA5LXWEBP001- US East Virginia AZ 5 Linux Web Server Production 001

This helps in better management of security groups. 

Practice 11) ELB on Amazon VPC:  When using Amazon ELB for Web Applications, put all other EC2 instances( Tiers like App,cache,DB,BG etc)  in private subnets as much possible. Unless there is a specific requirement where instances need outside world access and EIP attached, put all instances in private subnet only. Only ELBs should be provisioned in Public Subnet as secure practice in Amazon VPC environment.

Practice 12) Control your outgoing traffic in Amazon VPC: If you are looking for better security, for the traffic going to internet gateway use Software's like Squid or Sophos to restrict the ports,URL,Domains etc so that all traffic go through the proxy tier controlled and it also gets logged. Using these proxy/security systems we can also restrict the unwanted ports, by doing so,  if there is any security compromise to the application running inside Amazon VPC they can be detected by auditing the restricted connections captured from the logs. This helps in corrective security measure. 

Practice 13) Plan your NAT Instance Type: Whenever your Application EC2 instances residing inside private subnet of Amazon VPC are making Web Service/HTTP/S3/SQS calls they go through NAT instance. If you have designed Auto scaling for your application tier and there are chances ten's of app EC2 instances are going to make lots of web calls concurrently, NAT instance will become a performance bottleneck at this juncture. Size your NAT instance capacity depending upon application needs for avoiding performance bottlenecks. Using the NAT instances provides us with advantages of saving cost of Elastic IP and provides extra security by not exposing the instances to outside world for accessing the internet. 

Practice 14) Spread your NAT instance with Multiple Subnets: What if you have hundreds of EC2 instances inside your Amazon VPC and they are making lots of heavy web service/HTTP calls concurrently. A single NAT instance with even largest EC2 size cannot handle that bandwidth sometimes and may become performance bottleneck. In Such scenarios, span your EC2 across multiple subnets and create NAT's for each subnet. This way you can spread your out going bandwidth and improve the performance in your VPC based deployments.

Practice 15) Use EIP when needed: At times you may need to keep a part of your application services to be kept in Public subnet for external communication. It is recommended practice to associate them with Amazon Elastic IP and white list these IP address in the target services used by them 

Practice 16) NAT instance practices : If needed, enable Multi factor authentication on NAT instance. SSH and RDP ports are open only on sources and destination IP's, not global network (0.0.0.0/0). SSH / RDP ports are opened only on static exit IP's not dynamic exit IP's.  

Multi factor authentication ref link : Linux: http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/ 

Windows : http://www.rohos.com/2013/02/google-authenticator-windows-login/

Practice 17) Plan your Tunnel between On-Premise DC to Amazon VPC: 

Select the right mechanism to connect your on premises DC to Amazon VPC. This will help you to connect the EC2 instance via private IP's in a secure manner. 

• Option 1: Secure IPSec tunnel to connect a corporate network with Amazon VPC (http://aws.amazon.com/articles/8800869755706543) 
• Option 2 : Secure communication between sites using the AWS VPN CloudHub (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPN_CloudHub.html)
• Option 3: Use Direct connect between Amazon VPC and on premise when you have lots of data to be transferred with reduced latency (or) you have spread your mission critical workloads across cloud and on premise. Example: Oracle RAC in your DC and Web/App tier in your Amazon VPC. Contact us if you need help on setting up direct connect between Amazon VPC and DC.

Practice 18) Always span your Amazon VPC across multiple subnets in Multiple Availability zones inside a Region. This helps is architecting high availability inside your Amazon VPC properly. Example: Classification of the VPC subnet : WEB Tier Subnet : 10.0.10.0/24 in Az1 and 10.0.11.0/24 in Az2, Application Tier Subnet :  10.0.12.0/24 and 10.0.13.0/24, DB Tier Subnet :  10.0.14.0/24 and 10.0.15.0/24, Cache Tier Subnet : 10.0.16.0/24 and 10.0.17.0/24 etc

Practice 19) Good security practice is that to have only public subnet with route table which carries route to internet gateway. Apply this wherever applicable.

Practice 20) Keep your Data closer : For small scale deployments in AWS where cost is critical than high availability, It is better to keep the Web/App in same availability zone as of ElastiCache , RDS etc inside your Amazon VPC. Design your subnets accordingly to suit this. This is not a recommended architecture for applications demanding High Availability.

Practice 21) Allow and Deny Network ACL : Create Internet outbound allow and deny network ACL in your VPC. 

First network ACL: Allow all the HTTP and HTTPS outbound traffic on public internet facing subnet. 

Second network ACL: Deny all the HTTP/HTTPS traffic. Allow all the traffic to Squid proxy server or any virtual appliance. 

http://techlib.barracuda.com/display/BNGv54/How+to+Deploy+the+Barracuda+NG+Firewall+in+an+Amazon+Virtual+Private+Cloud 

Practice 22 ) Restricting Network ACL : Block all the inbound and outbound ports. Only allow application request ports. These are stateless traffic filters that apply to all traffic inbound or outbound from a Subnet within VPC. AWS recommended Outbound rules : http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_NACLs.html

Practice 23) Create route tables only when needed and use the Associations option to map subnets to the route table in your Amazon VPC

Practice 24) Use Amazon VPC Peering (new) : Amazon Web Services has introduced VPC peering feature which is quite useful one. AWS VPC peering connection is a networking connection between two Amazon VPCs that enables you to route traffic between them using private IP addresses. Currently it can be in same AWS region, Instances in either VPC can communicate with each other as if they are within the same network. Since AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware (which essentially means there is no single point of failure for communication or a bandwidth bottleneck).

We have seen it is useful in following scenarios :

1. Large Enterprises usually run Multiple Amazon VPC in single region and some of their applications are so interconnected that they may need to access them privately + securely inside AWS. Example Active Directory, Exchange, Common business services will be usually interconnected.
2. Large Enterprise have different AWS accounts for different business units/teams/departments , at times systems deployed by some business units in different AWS accounts need to be shared or need to consume a shared resource privately. Example: CRM , HRMS ,File Sharing etc can be internal and shared. In such scenarios VPC peering comes very useful.
3. Customer can peer their VPC with their core suppliers to have tighter integrated access of their systems.
4. Companies offering Infra/Application Managed Services on AWS can now safely peer into customer Amazon VPC and provide monitoring and management of AWS resources.

Practice 25) Use Amazon VPC: It is highly recommended that migrate all your new workloads inside Amazon VPC rather than Amazon Classic Cloud. I also strongly recommend to migrate your existing workloads from Amazon Classic cloud to Amazon VPC in phases or one shot which ever is feasible. In addition to the benefits of the VPC that is detailed in the start of the article, AWS has started introducing lots of features which are compatible only inside VPC and in the AWS marketplace as well there are lots of products which are compatible only with Amazon VPC.  So make sure you leverage this strength of VPC. If you require any help for this migration please contact me. 

readers feel free to suggest more.. I will link relevant ones in this article

Architecting Highly Available ElastiCache Redis replication cluster in AWS VPC

In this post lets explore how to architect and create a Highly Available + Scalable Redis Cache Cluster for your web application in AWS VPC. Following is the architecture in which the ElastiCache Redis Cluster is assembled:

• Redis Cache Cluster inside Amazon VPC for better control and security
• Master Redis Node 1 will be created in AZ-1 of US-West
• Redis Read Replica Node 2 will be created in AZ-2 of US-West
• Redis Read Replica Node 3 will be created in AZ-3 of US-West

You can position all the 3 Redis Nodes in different Availability zones for Achieving High Availability (or) you can position Master + RR 1 in AZ1 and RR 2 in AZ2. This reduces the Inter - AZ latency and might give better performance for heavily used clusters.
Step 1: Creating Cache Subnet groups:
To create Cache Subnet group  navigate to the dashboard of ElastiCache, select Cache Subnet groups and then click "Create Cache Subnet group". Add the Subnet Id and the Availability Zone you need to use for the ElastiCache cluster.

We have created Amazon VPC spreading across 3 availability zones. In this post we are going to place the Redis Master and 2 Redis Replica Slaves in these 3 availability zones. Since Redis will be most of the times accessed by your application tier it is better if you place them on Private Subnet of your VPC.
Step 2: Creating Redis Cache Cluster: 
To create Cache Cluster navigate to the  dashboard of ElastiCache, select Launch Cache Cluster and provide the necessary details. We are launching it inside Amazon VPC, so we have to select the Cache Subnet group .
Note: It is mandatory to create Cache Subnet group before Launch if you need ElastiCache Redis cluster in Amazon VPC.

For test purposes i have used m1.small EC2 instance for the Redis. Since this is a fresh Redis installation, i have not mentioned S3 bucket from where the persistent Redis Snapshot will be used as input. On successful creation of the Cache Cluster you can see the details in the dashboard.
Step 3: Replication Group Creation:
To create Replication group select the option of Replication Groups from dashboard and then select the “Create Replication Group”

Select the master Redis node "redisinsidevpc" created previously as the primary cluster id of the Cache cluster.  Give the Replication group id and description as illustrated below.

Note: Replication Group should be created only after the Primary Cache Cluster node is UP and running, else you will get the error as shown below.

On the successful creation of the Replication group you can see the following details. You can observe from below screenshot that there is only one primary node in US-WEST-2A and zero Redis Read Replica's are attached to it.

Step 4: Adding Read Replica Nodes:
When you select the Replication group, you can see the option to add Redis Read Replica. We are adding 2 Redis Read Replica named Redis-RR1 (in US-West-2B) and Redis-RR2 (in US-WEST-2C). Both the Read replica's are pointed to the master node "redisinsidevpc". Currently we can add up to 5 Read replica Nodes for a Redis Master Node. This is more than enough to handle Thousands of messages per second. If you combine it with Redis Pipeline handling 100K messages per second from a node is like cake walk.
Adding Read Replica 1 in Us-West -2B

Adding Read Replica 2 in US-West-2c

On successful creation you can see the following details of Replication group in the dashboard. Now you can see there are 3 Redis nodes listed with Number of read Replica's as 2. Placing the Read Replica's and master node in multiple AZ will increase the high availability and protects you from node and AZ level failure. On our sample tests inter AZ Replication deployments had <2 second replication lag for massive writes on master and <1 second replication lag between master slave inside same AZ deployments. We pumped @100K messages per second for few minutes on m1.large Redis instance cluster. 
In event, if you need additional read scalability i recommend to use more read Replica slaves added to the master. 
In your application tier you need to use the primary Endpoint "redis-replication.qcdze2.0001.usw2.cache.amazon.aws.com:6379" shown below to connect to Redis. 

If you need to delete/reboot/Modify you can make it through the options available here.

Step 5: Promoting the Read replica:

You can also promote any node as the Primary cluster using the Promote/Demote option. There will be only one Primary Node.
Note: This step is not part of the cluster creation process.

This promotion has to be carried out with caution and proper understanding for maintaining data consistency. 

Post was co authored with Senthil 8KMiles

Other related posts:

Billion Messages - Art of Architecting scalable ElastiCache Redis tier

Caching architectures using Memcached & Amazon ElastiCache
Deep dive into Amazon Elasticache
Distributed Cache On Steroids: Amazon ElastiCache
Launching Amazon ElastiCache in 3 Easy Steps
AWS Performance Tip 3: Use Amazon ElastiCache to improve application performance

Amazon ELB Multi region migration checklist

Amazon Elastic Load Balancing has a Amazon EC2 Regional scope. It needs to be migrated to alternate Amazon EC2 region in event of DR or during new migration setup . I am sharing my experience in this post as few checklists/areas that needs to be taken care during this Amazon ELB migration to alternate EC2 region:

1. Amazon ELB automatically distributes incoming application traffic across multiple Amazon EC2 instances in Multiple Availability Zones. Amazon EC2 regions have different levels of AZ's, US-East EC2 region has 5 AZ's and Singapore has 2 AZ's. When you are migrating the ELB make sure your configuration matches the levels of target Amazon EC2 region Availability zones .
2. When Amazon ELB is created on target Amazon EC2 region, the ELB endpoint will be different from the source one. This has to be re configured on your Route 53 and other thick clients during migration.
3. Since the ELB end point is different, if you had raised any pre-warming request to AWS support , please raise it again for the target region with new ELB end point. This is valid in use cases where you are moving the traffic from primary region to target region in event of outage. 
4. SSL certificates associated on the old Elastic Load Balancing service (source regions) need to be re configured to the new Elastic Load Balancing service in the Target region.
5. Security Groups are region specific and has to be migrated/recreated in the target region. Make sure the security groups of ELB in target region matches the source region
6. Amazon ELB is not an isolated service and usually it will be used in production with Amazon EC2, Auto Scaling group and Cloud Watch Alarms. In addition there will be health checks, time outs, thresholds etc configured specifically for an application in Amazon ELB. You need to ensure that all these items associated with Amazon ELB are transferred target region for proper functioning of the application. Using Amazon CloudFormation templates for creating infrastructure properties will surely help and ease the efforts involved during such ELB migration.
7. To load balance your EC2 instances launched in default VPC, you have to create your load balancers within your default VPC. When you create a load balancer within default VPC, Elastic Load Balancing automatically creates a security group by defining the ports specified for the load balancer to be opened. Default VPC is currently not available in US-East. In case your Source region is US-West and you are planning your DR or migration with Target region as US-East, you need to be aware of this situation. 
8. In case Amazon ELB and Internal ELB are used inside Amazon VPC, you should ensure that the IP address ranges being used in source and target regions matches and aligns properly, so that routing and load balancing continues to work after migration. 

Other Multi Region Migration articles:

Security Groups - Multi Region Migration checklist

Elastic IP - Multi region Migration checklist, tips , best practices

EC2 AMI Copy - Multi Region Migration

MySQL Amazon EC2 Cross region Master-Slave Replication using SSL

Amazon EBS Snapshot copying- Performance, Tips and How to

Amazon EC2 AMI Copy Feature - Performance, Tips and How To

Configuring Citrix NetScaler Load Balancing on AWS

Citrix NetScaler is a popular Load balancer in the Enterprise world. Hardware and virtualized NetScaler has been serving many popular enterprise online assets for years. NetScaler supports many load balancing algorithms like (Round robin, Least connection, source IP Hash etc..) + comes with many more features. Citrix Netscaler with its powerful load balancing capabilities serves many websites under it inside an enterprise setup. Citrix NetScaler is usually preferred in AWS by :

• Enterprises which already have some partnership with Citrix and have some form of NetScaler licenses / agreements with Citrix
• Enterprises which want proper support for their load balancing tier which other OSS LB providers were not able to meet
• Enterprises which already have trained IT staff in Citrix products including NetScaler and do not want change
• Enterprises which wants Load balance tier to provide them with Security, Performance in addition to wide variety of LB options.

In this article i am going to share the experience on configuring Citrix NetScaler in AWS cloud. Citrix NetScaler will be used inside public subnet of Amazon Virtual Private Cloud (VPC) and will load balance requests between 2 web/App EC2 instances running in private subnet of the Amazon VPC. The Web/App amazon EC2 are deployed in multiple subnets in Multi-AZ architecture inside the Amazon VPC. 

Following is the step by step configuration details for the same:

Step 1: Login to AWS market place using the console using IAM user account and Click Amazon EC2 tab and Click the Launch Instance option.

Step 2: Find the Citrix NetScaler Instance and choose the right instance based on your application load and features needed. For example:  if your application load will not exceed 10 Mbps and you need round robin load balancing, you can choose NetScaler Standard Edition 10 Mbps as your instance type. If your application has heavy load and you are planning to leverage other features of Netscaler like performance, security etc, you can choose NetScaler VPX Platinum Edition - 1000 Mbps option as well. To know more about Citrix NetScaler on Amazon refer link https://aws.amazon.com/marketplace/seller-profile?id=fb9c6078-b60f-47f6-8622-49d5e1d5aca7

Step 3: Click “Launch with EC2 Console” option and launch the Citrix NetScaler in suitable+available Amazon EC2 region of your choice.

Step 4: Select Amazon VPC IP range example: 10.100.0.0/16 in our case, choose the public subnet for Citrix NetScaler EC2 instance and launch the EC2 Instance as shown in the below screen shots.

Step 5: Once the Instance status is “2/2 check passed”, attach one Amazon Elastic IP to Citrix NetScaler default ENI- Elastic Network Interface.

Step 6: Use the Amazon Elastic IP in your browser.Use the default user name and password “nsroot” and login into Citrix NetScaler console.

Step 7:Click configuration tab -> expand the Network and add the IP address  (The virtual IP address you have to configure for the load balancing)

Step 8: Expand the system option on the left panel and click the settings and click the “configure basic features” settings on the right panel. Citrix NetScaler offers many features like :

• Integrated Caching, HTTP compression SSL offloading for performance
• Content Filtering, Access Gateway, App Firewall, Authentication etc for Security

In this post we are going to explore only Load balancing feature, so select the “Load Balancing” and click OK.

Step 9: Select and expand the load balancing feature on the left panel and click the services.

Step 10: Click the “Add” button and give the web/app EC2 instance details to be load balanced. We have two Web/App EC2 with 10.100.5.15 and 10.100.4.15 in two subnets in Multi-AZ architecture. Both these web/app ec2 are attached to the NetScaler for Load Balancing. Illustrated in below screenshots.

Click “Create” , then check the service status is “UP”

Step 11: Click the “Virtual Servers” on the left panel.Type the Virtual Server name and the IP address, protocol and port number. Then select the service for the Web/App EC2 Servers.

Step 12: Select the “method assistance” tab and select the load balancing algorithms.   
The load balancing algorithm defines the criteria that the NetScaler appliance uses to select the service to which to redirect each client request. Different load balancing algorithms use different criteria. For example, the least connection algorithm selects the service with the fewest active connections, while the round robin algorithm maintains a running queue of active services, distributes each connection to the next service in the queue, and then sends that service to the end of the queue. Some load balancing algorithms are best suited to handling traffic on websites, others to managing traffic to DNS servers, and others to handling complex web applications used in e-commerce or on company LANs or WANs. The following table lists each load balancing algorithm that the NetScaler appliance supports, with a brief description of how each operates.

LEASTCONNECTION: Which service currently has the fewest client connections. This is the default load balancing algorithm.

ROUNDROBIN:Which service is at the top of a list of services. After that service is Selected for a connection, it moves to the bottom of the list.

LEASTRESPONSETIME: Which load balanced server currently has the quickest response time.

URLHASH:A hash of the destination URL.

DOMAINHASH:A hash of the destination domain.

DESTINATIONIPHASH:A hash of the destination IP address.

SOURCEIPHASH:A hash of the source IP address.

SRCIPDESTIPHASH:A hash of the client's IP address and port.

LEASTBANDWIDTH:Which service currently has the fewest bandwidth constraints.

LEASTPACKETS:Which service currently is receiving the fewest packets.

CUSTOMLOAD:Data from a load monitor.

TOKEN:The configured token.

LRTM:Fewest active connections and the lowest average response time.

The default is “least connection”.For simplicity purpose choose for “Round Robin” as your Load Balancing method for this post.

Then click create and check the status of the Virtual servers is “UP”. Note the method now is displayed as Round Robin.

Step 13: Now that the simple Load balancing configuration is completed in Amazon VPC, let us do a simple testing of our config till this stage. Go to the web browser in the Jump box provisioned in the VPC. Use the Virtual Server IP address of the Load balancer and check whether the web application is accessible

Step 14: In case you want to check the client request details, Login to NetScaler in CLI mode. Use the following command ”stat lb vserver NS-LB01”

Before user access the web application, load balancing service status is as follows:

After user accessed the web application, load balancing status is as follows:

Step 15: How to access the web application in public Internet ? Select the NetScaler Instance in EC2 console and select the “Managed Private IP Address” option.

Step 16: Click the “Assign a secondary private address” option and enter the IP Address and click the “Yes Update” option.

Step 17: Then go to Elastic IP window, select the Elastic IP Address (EIP) and right click the EIP and select the “Associate IP Address” 

Step 18:Select the NetScaler Instance on the “Instance” option, Select the IP Address from “Private IP Address” option and Click “Yes Associate”. The EIP will attach with the Secondary IP Address of NetScaler Instance.

Now Use the Elastic IP (Example: 54.244.36.218) in your browser and access your application from Public Internet.

Understanding Amazon Elastic Block Store (EBS) in detail

Amazon Elastic Block Store (EBS) provides block level storage volumes for use with Amazon EC2 instances. In a typical block level storage device, raw storage volumes are created and then the server-based operating system connects to these volumes (over Fibre Channel, iSCSI etc) and uses them as individual drives. This fundamental flexibility makes block level storage usable for variety of application needs like file storage, database storage, virtual machine volumes and more. You can have variety of file system running on the block level storage, example NTFS for windows and ext3/XFS etc for Linux. In simpler terms Amazon EBS is like a massive SAN (Storage Area Network) in the AWS infrastructure. The physical storage could be hard disks, SSD’s etc under the EBS hood. Amazon EBS is one of the most important and heavily used storage services of AWS, even the building blocks like RDS, DynamoDB, CloudSearch etc possibly rely on EBS in the Cloud.

In Amazon EBS you can allocate a disk volume of 1GB to 1TB in size and data written will persist independently (unlike ephemeral disks) from the life of an Amazon EC2 instance attached with it. The volume is internally stored on redundant disks in an Amazon Availability Zone scope, which means that the EC2 instances using the EBS Volumes also should reside on the same AZ. The data is automatically replicated within the same Availability Zone (internally some form of RAID is employed by AWS) to prevent data loss due to failure of any single hardware component. Since the Amazon EBS lifetime is separate from the instance on which it is mounted, you can detach it and later attach it on another EC2 instance in the same availability zone.

Following are the few definitions which readers need to be conversant before going deep into this multi part article series :

IOPS	Input Output Operations Per Second
Throughput	Read / Write rate to storage in seconds (MB/s)
Capacity	Volume of Data that can be stored (GB)
AZ	Availability Zone within the Same Amazon EC2 region
SAN	Storage Area Network
RAID	Redundant Array of Independent Disks

EBS Volumes can currently be classified into two types. They are Standard EBS Volumes and Provisioned IOPS Volumes. Standard EBS Volumes are the first generation EBS Volumes that are suitable for sequential IO workloads. PIOPS Volumes are more consistent and are targeted towards OLTP workloads. Let us explore in detail about each type of EBS Volumes ?  what are the positives and negatives of using the same ? Any best practices, tips, points to remember while incorporating the same in the architecture. Refer the articles here Standard & PIOPS.

One of the biggest advantages of running your infrastructure in Amazon Web Services is the flexibility and the choice it offers to the architects while making critical decisions. Though cost savings is not the main reason why users migrate to AWS, it is also one of the important factors that needs to be taken care for efficient on going operations in on demand nature of Amazon Cloud. Making the right choice between Standard EBS Volumes and PIOPS volumes can have impact in the infrastructure cost savings in AWS infrastructure. By having an detailed understanding of what use cases best fit these volume types, you can accordingly provision suitable volume types in the architecture stack. Choosing a wrong volume can lead to a cost leakage between 20 - 70% based on the analysis done. Refer the article here. 

I read a line in AWS Documentation about EBS that " 10% of your provisioned IOPS 99.9% of the time" - What does this mean ? and why it is important ? Refer article here

We all know that AWS team constantly listens to the user inputs and delivers their product road map tying them. One such instance is their introduction of EBS Optimized EC2 instance. In normal EC2 instance, the Network is shared between your front facing workloads and your EBS IO operations. This often leads to congestion in high traffic web sites that rely a lot on OLTP database systems. Even though you RAID your EBS volumes to extract more IOPS, if the pipe between the EC2 instance and your EBS is constantly choked you end up scaling your instance types to get larger bandwidth. On cost and compute perspective , this is not an ideal scenario. AWS introduced EBS optimized instances specifically to tackle this situation and help users with better performance while using EBS volumes. Refer this article to understand how EBS optimized instances can help you extract better performance from your architecture.

Extracting higher performance from EBS is always an topic of interest to me as well lots of AWS enthusiasts and users. In order to achieve the same you need deeper understanding on IO latency and IO Block size. The IOPS rate you get usually depends on the I/O size of your applications’ reads and writes. It is very important to know the I/O size your application operates and accordingly expect the performance from EBS Volumes.Latency is a measure of how long it takes for a single I/O request to happen from the apps perspective.Only IOPS numbers alone are meaningless without considering additional metrics such as latency, read/write % and I/O block size etc.
Let us explore in this section, how these two factors can affect your performance expectation while using Amazon EBS and why it is important to know about them before tuning  Refer articles here IO Latency and IO Block Size.

Performance extraction from Amazon EBS :
Pre warming the EBS Volume. Click here.
EBS Striping. Click here.

Since EBS volume redundancy is limited to Availability Zone scope , it becomes a necessity incrementally backup the data stored in them frequently to a much more robust system like S3. EBS snapshot is one such technique that allows us to backup the state of a system at a particular point in time to S3 and they are incremental in nature. Users have lots of confusion on how these snapshots work internally, what happens if i delete an older snapshot ? what benefits it brings to the operations ? In this section we deep dive into the workings of EBS snapshots and answer questions like what are some of the objectives for using them? How to achieve consistent snapshots in AWS? what are the best practices, tips , points to note while using them. Refer article here.

Though EBS snapshots are incremental in nature , it is recommended to have a proper snapshot deletion and retention strategy in place. If this mechanism is not addressed as part of your on going IT operations, you can end up with a 70% cost leakage in some scenarios. Refer this article to understand in detail the analysis behind the cost savings. 

EBS snapshots have Amazon EC2 regional scope. In case you are planning to geographically expand or have data backed up on different Amazon EC2 region at regular intervals to minimize data loss and recovery time, you can use EBS snapshot copy feature for this purpose. How to copy EBS snapshots, Time taken between regions for copying ? Points to remember while implementing the same are covered in this article. Click here to understand more about EBS snapshot copy feature.

Common best practices for securing your EBS like IAM your EBS volumes, Wiping Data from EBS Volumes, Sharing Amazon EBS snaphsots,Storing AWS Credentials on an EBS Snapshot Securely are discussed in this article. If you want deeper protection for EBS you can also encrypt the volume using TrendMicro Secure Cloud. Check this article to get instructions for implementing the same in Amazon Web Services infrastructure

EBS Article Series Index

Part 1: Understanding Amazon Elastic Block Store
Part 2: Understanding Standard EBS Volumes
Part 3: Understanding EBS PIOPS Volumes
Part 4: Understanding EBS-Optimized Instances
Part 5: Understanding Latency in EBS
Part 7: 10% of your provisioned IOPS 99.9% of the time
Part 8: Performance Tuning - Pre Warming the EBS volume
Part 9: Performance Tuning - EBS Striping
Part 10: Performance Tuning - IO Block Size
Part 11: Understanding Amazon EBS Snapshots
Part 12: Securing Amazon EBS volumes - EBS Encryption using SecureCloud (new)
Part 13: Amazon EBS Security Best practices and tips
Part 14: How proper EBS Snapshot Retention strategy can save costs (new)
Part 15: Amazon EBS Snapshot copying- How-to, Performance and Tips (new)
Part 16: Make right choice between PIOPS vs Std Volumes and save cost (new)