Category: AWS


Why CloudTern Chose Kubernetes for Container Orchestration?

In the traditional software development environment, creating an application was a simple process of writing the code. However, the rapid innovation that has brought-in a myriad of technologies, tools, frameworks, architecture and interfaces adds enormous complexity to application development environments. The advent of smartphones has opened up another world of mobile computing environment which adds up to this challenge. Developers now have to consider all these aspects while creating an application. Containerization solves all these challenges enabling developers to focus on just the application and not worry about runtime environment differences.

An Overview of Containerization

A container is a standalone and portable software unit that is packaged with code and its entire runtime environment such as binaries, libraries, dependencies, configuration files etc. By abstracting away the underlying infrastructure, OS and platform differences, containers facilitate seamless movement of applications between different computing environments. Right from a large enterprise application to a small microservice, containerization can be applied to any type of application or service. The absence of the OS image makes containers lightweight and highly portable.

The Evolution of Containerization

Containerization is not a new concept and has been around for decades. Unix OS Chroot was the first system that implemented containerization, providing disk space for each process. Derrick T. Woolworth extended this feature in 2000 wherein he added a sandboxing feature for file system isolation in FreeBSD OS. While Linux implemented this feature in its VServer in 2001, Solaris released containers for x86 in 2004. Similarly, Google introduced Process Containers in 2006 to isolate resources. Linux introduced container manager, LXC in 2008. CloudFoundry introduced LXC in Warden which was able to run on any operating system. Google introduced Linux app containers in 2013 which was called lmctfy. However, containerization gained widespread adoption with the advent of Docker in 2013.

Virtual Machines Vs Containers

Containers are often confused with virtual machines. Containers and virtual machines share a lot of similarities in terms of resource isolation and allocation but differ in the functionality. A virtual machine is created by abstracting physical resources from a machine and deployed to run in an isolated computing environment to deliver the functionality of a computing device. Each virtual machine contains the copy of the operating system and all the dependencies of the application running on it. A hypervisor is used to run multiple VMs on a single machine. As it contains the full copy of OS, it is larger in size and takes more time to boot. 

While a VM virtualizes hardware resources, a container virtualizes the operating system. Multiple containers share the same OS kernel and run in isolation on the same machine. As there is no OS, containers are lightweight, portable, run more applications and take less time to boot. By combining both these technologies, organizations can gain more flexibility in managing and deploying a range of applications.

Benefits of Containerization

Containers bring amazing benefits to organisations. Here are a few of them:

Highly Portable

While the absence of a full OS copy in a container makes it light-weight, the abstraction of underlying infrastructure makes it highly portable. It means, containers can be easily deployed in an on-premise data center, public cloud or on any individual laptop. Containers run on Windows, MAC, Linux, virtual machines or even on bare metals, offering higher flexibility for development and deployment of applications. 

Improved Efficacies and Increased Productivity

Containers clearly define the role of developers and operations teams. With language runtimes, software libraries and dependencies, containers assure predictable and consistent environments, regardless of where the applications run. As such, operations and development teams can stop worrying about software differences across environments and focus more on improving performance of apps, resulting in more productivity and efficacies.

Faster and Better Application deployment

Containerization significantly improves the build, test and deployment of applications. Compared to virtual machines that take minutes to load, containers can be spinned up within seconds. They share a single OS kernel, boot much faster and consume less memory. By packaging an app along with its dependencies into isolated software units, containers facilitate easy replication of apps on multiple machines across the clusters, rapid deployment and scaling. 

Docker – A Synonym for a Container

Docker is an open-source tool that helps both development and operations teams in building, managing and deploying containers with ease. Docker was originally created for Linux but now supports MAC and Windows environments. Docker Engine is a runtime environment that lets you build and run containers and store these images in Docker Hub container registry.

As a leading cloud solutions company, CloudTern manages containerization needs for multiple companies. Docker offers the flexibility to integrate it with major infrastructure automation and configuration management solutions such as Puppet, Chef, Ansible, SaltStack etc. or independently manage software environments. In addition, Docker allows us to integrate it with the CI/CD pipeline and run multiple development environments that are similar to real-time production environments on a single machine or try different configurations, servers, and devices etc. for running test suites. As such, our clients were able to deploy software more frequently and recover faster while significantly reducing the change failure rate.

While there are other container management tools such as RKT, Canonical, Parallels etc., Docker is the most popular tool that has now become a synonym for a container. The fact that Docker can be used on any operating system or cloud makes it the first choice for many. At CloudTern, we proactively monitor technology changes and offer the best IT solutions for our clients. So, Docker is our first choice for all containerization needs.

Why Container Orchestration?

Looking at the significant benefits offered by containers, several organizations are now implementing container technology into their CI/CD environments. As containers are quick to spin up, lightweight and portable, thousands of containers are created and deployed across the infrastructure. A typical IT infrastructure runs hundreds of containers that come with a shorter lifespan which pose great complexity in infrastructure monitoring.  You need to closely monitor and manage them to know what’s running on each server. This is where cloud orchestration tools come to the rescue.

Kubernetes, Mesosphere and Docker are the most popular cloud orchestration tools. 

An Overview of Kubernetes

Kubernetes is the most widely used container orchestration tool in recent times. Kubernetes was developed by Google and released in 2014. It is now managed by Cloud Native Computing Foundation (CNCF). Kubernetes allows organizations to easily automate deployment, scaling and management of container applications across a cluster of nodes. It is a standalone software that can independently manage containers without Docker or work with Docker in tandem. 

A Quick Overview of Kubernetes Architecture

The kubernetes architecture consists of two core components:

  1. Nodes (bare metals or virtual machines): Nodes are again divided into two components: 
    1. Master: A master node is where the Kubernetes is installed. The Master node controls and manages scheduling of pods across worker nodes where the application runs while maintaining the state of the cluster at its predefined state. Multiple master nodes are implemented to maintain high availability. Here are the key components of a master node.
      1. Kube-contoller-manager: It is responsible to maintain the desired state of a cluster by listening to the kube-apiserver about the information of the current state. 
      2. Kube-scheduler: It is the service that schedules events and jobs across the cluster based on the availability of resources of predefined policies via the kube-apiserver.
      3. Kube-apiserver: It is the API server that enables UI dashboards and CLI tools to interact with Kubernetes clusters.
      4. Etcd: It is the master node storage stack that contains definitions, policies, state of the system. 
    2. Worker Node: This is where the actual application runs. It contains the following components:
      1. Docker: It contains the Docker engine to manage containers.
      2. Kubelet: It receives instructions from the master node and executes them while sending information about the state of the node to the master.
      3. Kube-proxy: This service facilitates communication between microservices and pods within the cluster as well as connect the application to the outside world.
  2. Pods: A pod is a Kubernetes basic unit of deployment. All containers required to co-exist will run in a single pod. 

Why CloudTern Chose Kubernetes?

As a leading cloud managed Services Company, CloudTern handles cloud networks of multiple organisations. A typical IT network comprises multiple nodes that can be anything from virtual machines to bare metals. Multiple nodes are implemented by IT administrators for two important reasons. Firstly, high availability is a key requirement for cloud-based services wherein the application should always be available to users even when a node is down. So, a robust infrastructure has to be set up. Secondly, scalability is a key concern. As the application traffic increases, more containers should be dynamically added or removed on-demand. Multiple containers of an application should talk to each other as well. 

Docker Swarm is a container orchestration tool offered by Docker. It uses Docker API and works in tight integration with Docker. However, CloudTern chose Kubernetes because Kubernetes efficiently co-ordinates a large cluster of nodes and scales better in production compared to Docker that runs only on a single node. It helps you manage and orchestrate container resources from a central dashboard.

Kubernetes securely manages networking, load-balancing and scales well. In addition, it allows you to group containers based on a criteria such as staging environments or implement access permissions. So, it eliminates the need to mock up the entire microservices architecture of an application for the development team. You can deploy software across pods in a scale-out manner and scale in deployments on-demand. It gives clear visibility into the deployment process wherein you can check the completed, in-process and failed deployments from a single pane. You can save time by pausing and resuming a deployment at your convenience. The version control feature allows you to update pods with latest images of the application and roll back to a previous one, if needed.

With support for 5000 nodes and 300,000 containers, Kubernetes works well for organizations of all sizes. Combined with Docker, Kubernetes offers a highly scalable cloud orchestration system delivering fast and reliable applications. Kubernetes enjoys a large and vibrant community which means you can always be up to date with what’s happening with the tool or get help to resolve any issues. 

The Bottom Line

Kubernetes is not just a personal choice. Today, Kubernetes is the market leader in container orchestration. According to StackRox, Kubernetes market adoption reached 86% by Spring 2019.  These market statistics once again affirm the fact that CloudTern always offers the right tools for the right IT tasks.



Laravel project setup in AWS

Below are the steps to set up Laravel project in AWS instance.

  • Login to the AWS instance.
  • sudo yum update
  • sudo yum install httpd24 php56 php56-pdo php56-mbstring php56-mcrypt php56-mysqlnd
  • sudo curl -sS | php
  • sudo mv composer.phar /usr/local/bin/composer
  • sudo yum install git
  • cd /var/www/html
  • sudo git clone
  • Rename the cloned repository/project directory if required.
  • cd project-name
  • sudo vi .env
  • Change the MySQL connection details.
  • php artisan config:cache
  • cd /etc/httpd/conf
  • sudo vi httpd.conf
  • Insert below commands

          <VirtualHost *:80>


               DocumentRoot /var/www/html/project-name/public

               <Directory /var/www/html/project-name/>

                    AllowOverride All



  • sudo service httpd start

How to import VM image to AWS

One of the coolest features I like about AWS is it not only gives you the powerful images through AMI but also allows you to import your VM images running in your data center as well. In this, I would like to show you how simple it is to import the VM image into the AWS

The prerequisites for VM import are

For S3 Bucket I am assuming name “my-vm-imports”

Creating IAM Role

You cannot create using the AWS management console. You have to follow the aws- only

  1. create a trust policy trust-policy.json

   "Version": "2012-10-17",

   "Statement": [


         "Effect": "Allow",

         "Principal": { "Service": "" },

         "Action": "sts:AssumeRole",

         "Condition": {


               "sts:Externalid": "vmimport"






2. Using aws command line create a role vmimport

aws iam create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json

3. Create a file named role-policy.json with the following policy


   "Version": "2012-10-17",

   "Statement": [


         "Effect": "Allow",

         "Action": [





         "Resource": [





         "Effect": "Allow",

         "Action": [



         "Resource": [





         "Effect": "Allow",








         "Resource": "*"




4. Use the following command “put-role-policy” to the role we created before.

aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document file://role-policy.json

Next steps :

  1. Upload the VM image to S3
aws s3 cp file_path s3://my-vm-imports

2. Create a container file which contains the s3 bucket name, format, description and key name in the s3 bucket. Save this file as JSON



    "Description": “My VM",

    "Format": "ova",

    "UserBucket": {

        "S3Bucket": “my-vm-imports",

        "S3Key": "my-vm-imports/myVm.ova"



Note: Only OVA,VMDK image formats are supported in AWS

4. Finally, import the image from S3 with import-image command. After that, your image(AMI) will be ready for use

aws ec2 import-image —description “Linux or Window VM” —-disk-containers file://container.json

Thanks for Reading.

Best Regards



Hybrid Cloud Architecture with CISCO CSR 1000v

Cisco CSR 1000v series is a router software appliance from Cisco. It provides enterprise routing, VPN, Firewall, IP SLA, and more.CSR 1000v can be used to connect multiple VPC across all-region in AWS Cloud and on-premise networks. Thus it can be used avoid managed VPN service from AWS.

In AWS, you can find Cisco CSR 1000v in AWS marketplace which has 30 days free trial to test it out. AWS Marketplace for Cisco. Be aware this is not cheap, it will cost you EC2 Instance charges. All instance types are not supported for CSR 1000v. It supports only m3 and c3 instance family types.

Cisco CSR 1000v Can be used in various network models in cloud like Transit VPC, multi-cloud Network.

Following is the Architecture I have used to connect multiple VPC.


The two VPC’s are one in N.Virginia region and other is in Ohio Region. And Each VPC has Internet Gateway and were connected over VPN. On Ohio region, we used AWS managed VPN service to connect VPC in N.Virginia region VPC. And On-Premise Edge Router we used Cisco RV110W small business router. In this Post, I would like to mention the steps to follow to establish VPN over two VPC’s spread in two different regions in AWS.

Steps to create VPC’s in two regions:

  1. Create VPC in N.Virginia Region with CIDR and attach Internet Gateway to it. you can do it from CLI or through the management console.
    aws ec2 create-vpc --cidr-block --region us-east-1
                "Vpc": {
                    "VpcId": "vpc-848344fd",
                    "InstanceTenancy": "dedicated",
                    "Tags": [],
                    "CidrBlockAssociations": [
                            "AssociationId": "vpc-cidr-assoc-8c4fb8e7",
                            "CidrBlock": "",
                            "CidrBlockState": {
                                "State": "associated"
                    "Ipv6CidrBlockAssociationSet": [],
                    "State": "pending",
                    "DhcpOptionsId": "dopt-38f7a057",
                    "CidrBlock": "",
                    "IsDefault": false
    aws ec2 create-internet-gateway --region us-east-1
                  "InternetGateway": {
                      "Tags": [],
                      "InternetGatewayId": "igw-c0a643a9",
                      "Attachments": []
    aws ec2 attach-internet-gateway --gateway-id <<IGW-ID>> --vpc-id <<VPC-ID>> --region us-east-1
  2. Create two subnets in N.Virginia Region VPC, one for CSR 1000v with CIDR and another subnet with CIDR
    aws ec2 create-subnet --cidr-block --vpc-id <<VPC-ID>> --region us-east-1
                  "Subnet": {
                    "VpcId": "vpc-a01106c2",
                    "AvailableIpAddressCount": 251,
                    "MapPublicIpOnLaunch": false,
                    "DefaultForAz": false,
                    "Ipv6CidrBlockAssociationSet": [],
                    "State": "pending",
                    "AvailabilityZone": "us-east-1a",
                    "SubnetId": "subnet-2c2de375",
                    "CidrBlock": "",
                    "AssignIpv6AddressOnCreation": false
    aws ec2 create-subnet --cidr-block --vpc-id <<VPC-ID>> --region us-east-1
                  "Subnet": {
                    "VpcId": "vpc-a01106c2",
                    "AvailableIpAddressCount": 251,
                    "MapPublicIpOnLaunch": false,
                    "DefaultForAz": false,
                    "Ipv6CidrBlockAssociationSet": [],
                    "State": "pending",
                    "AvailabilityZone": "us-east-1b",
                    "SubnetId": "subnet-2c2de375",
                    "CidrBlock": "",
                    "AssignIpv6AddressOnCreation": false
  3. Create Route Table in N.Virginia VPC which will have the default route to Internet Gateway.And associate CSR subnet to it.

4. Launch the CSR 1000v from AWS MarketPlace with the one-click launch. Link To AWS Marketplace, you can ssh into the CSR 1000v instance using ec2-user.Attach Elastic IP to the CSR instance which will act as Customer Gateway in N.Virginia Region VPC. In later steps, we will configure the router to add Static routes to other subnets in VPC and setting BGP to propagate routes over VPN Connection with other VPC.

5. In a similar fashion create VPC in AWS Ohio region with CIDR And create two subnets with CIDR and

Steps to Create VPN connection in AWS Ohio VPC

  1. Create Customer Gateway. Open VPC management console at In navigation pane choose Customer Gateway and then create new Customer Gateway. Enter Name, Routing type as Dynamic and EIP of the CSR 1000v instance in N.Viriginia Region VPC. ASN number is 16-bit and must be in the range of 64512 to 65534.
  2. Create VPG and attach to the VPC.In the Navigation Pane choose Virtual Private Gateway and create VPG.
  3.  Now Create VPN connection. In Navigation Pane Choose VPN Connection, Create New VPN Connection. Enter the Name, VPG and Customer Gateway which we have created previously, select routing type as Dynamic and create VPN connection.

It will take few minutes to create VPN connection. When it is ready to download the configuration for Cisco CSR from the drop-down menu.

Steps to establish VPN Connection on CSR 1000v

  1. Add static routes of other subnets in VPC(N.Virginia) to CSR 1000v. Every subnet in AWS has a virtual router with IP address of Subnet CIDR +1. As CSR router will be in Subnet  the virtual router IP address will be The Virtual Router on each subnet has a route to other all subnets in the VPC.
    >Configure terminal
    #ip route
  2. Configure BGP. Choose the ASN number which you gave while creating Customer Gateway in Ohio VPC. Above we gave 64512
    > Configure terminal
    (config)#router bgp 64512
    (Config-router)# timers bgp keepalive holdtime
    (Config-router)# bgp log-neighbor-changes
    (Config-router)# end

    This step might not be necessary. But as good practice, I have applied the above configuration before copying the configuration file that is downloaded before.

  3. Apply the Configurations that are downloaded previously when VPN Connections Created. After you have applied those setting on CSR you can see on the management console that both the tunnels of VPN as UP.

Testing to check connectivity between two VPC’s

  1. Launch an instance in subnet1 in Ohio region VPC’s with Public IPv4. SSH into the instance and ping the CSR 1000v instance private IP.
  2. Similarly, you can check connectivity with Ohio Region VPC by pinging the instance in subnet1 in Ohio region VPC with its Private IP.

Troubleshooting :

> Route Propagation must be added to the route table in Ohio Region VPC.

> You must configure CSR 1000v as NAT, so the subnets in N.Virginia region can access the hosts in Ohio region VPC via CSR 1000v. You need to Update the route table with target fo CSR 1000v instance-id after making it as NAT.

> Allow ICMP in Security groups on all instances.

Thanks and Regards


AWS Solution Architect @CloudTern


VPC Design Principles

Virtual Private Cloud(VPC) creation is the first step in building your infrastructure in AWS Cloud. AWS gave the flexibility to create VPC based on RFC4632 . Major Components of VPC : VPC CIDR, Subnets, Route Table, ACL and Security Groups. The VPC creation is a straightforward method just grab a CIDR based on RFC4632  but subnetting the VPC can consider the  following principles.

Creation of Subnets:

Primary reasons to create Subnets

  1. You need hosts to be routed successfully.(Private facing or Public facing)
  2. Want to distribute Workload across multiple AZ’s( Availability Zones) for fault tolerance.
  3. Create Subnets for hosts that require additional layer of  Security using ACL ( Access Control List)

Subnet the network into smaller networks which can be considered as  Public Subnets, Private or VPN only subnets. These networks are supernets and not the actual subnets we create. Then subnet each supernet into smaller networks which you fit your hosts into it.

Note* : AWS reserves 5 IPs when you create a subnets. So more subnets you create more ips you will lose. For example for subnet following IP’s are resolved

  1. network address
  2. Virtual Router address
  3. DNS address
  4. Reserved by AWS for future use.
  5. Broadcast address

Route Tables

All the hosts within VPC can be routed to other hosts in the VPC using an implicit virtual router . A Default Virtual Router would be created when you create the subnet. For example a subnet with CIDR will have Virtual Router with IP ( Subnet CIDR + 1). This Router will utilize the route table entries of the subnet associated with.

Each Subnet should be associated with a Route Table for traffic to flow.If a subnet is not associated to any route table, it will use the default Main Route Table. Route Table can be associated with multiple subnets.

  1. Create Route Tables for Subnets that need different Routing requirements(Public facing or Private facing).
  2. Create Route Table for subnets that require more specific routing. For example a subnet may be needed to allow traffic only from a pool of IP address.

Access Control List(ACL)

ACL Provide security at Subnet Level. You can control what traffic to flow in and out of a subnet. ACL are stateful, i.e you have to define both ingress and outgress traffic in the rule list.

You can find more at ACL Overview

Create ACL if you want restrict any traffic to flow to the hosts in the subnets.

Network Address Translator (NAT)

A NAT is used to provide Outbound internet to the hosts inside Private Subnets. Route Tables for Private Subnets has to updated with logical id of NAT to provide Outbound Internet Connectivity to hosts inside private Subnet.

Based on the above principles ,a Concrete Example for  Creating VPC in Practice is below

  1. Subnet the VPC CIDR to Public facing or Private facing Subnets.
  2. All Private facing subnets would be associated with a single Route Table, and  ACL. The same would be applied for VPN Subnets and Public Subnets with different Route Tables and ACL
  3. Create a Subnet if more security is needed at subnet level using ACL and associate the subnet to Route Table.

The following figure shows the summary of VPC Design in AWS


Cloud-Init Cheat Sheet

Cloud-init is a multi-distribution package that handles early initialization of cloud instances. Some of the things cloud-init can do are

  • set up the hostname.
  • setting up a local user.
  • Updating and installing the packages on Linux.
  • Disk setup and mounting the additional volumes.

More information can be found at Cloud-Init

Today most of the distribution support cloud-init and using cloud-init can run all cloud providers(AWS, Azure, GCP). In this article, I want to show some of the code-snippets I have tried in AWS with different distributions mainly Ubuntu and Amazon Linux.

#To create hostname :

#set the hostmachine name

This will set the hostname of the deployed instance to But the default AMI from Amazon Linux does not support changing the hostname. You need to launch the instance and change the preserve_hostname to false in etc/cloud/cloud.cfg.Then you need to build an image from that instance and launch a new instance from the build image with the above cloud-config script to change the hostname.

#To add additional users to the instance

 - name: bob
   groups: admin, root


This will add user bob to the instance along with the default user created by distro’s like for Amazon Linux default user ec2-user and for Ubuntu default user is ubuntu.

#To update packages and install new ones:

 - pwgen
 - nginx

The above will update the distro package system and install the pwgen and nginx packages.

#Disk Setup and mount the additional EBS volumes.

# - /dev can ommited for device names starting with xvd, sd, hd, vd
# if device does not exist at the time, an entry will still be written to /etc/fstab
- [xvdb, /data,"auto","defaults,nofail", "0", "0"]

#setup the file system on the device
 - label: data
   filesystem: 'ext4'
   device: '/dev/xvdb'
   partition: auto
 - mkdir /data

This will basically set up the disk to filesystem ext4 and add the mounting device to /etc/fstab in Linux.

Thanks for viewing.

Best Regards



Custom AMI with Custom hostname

I am using Amazon web services for a while now. And using it allowed me to have hands dirty on various services. In AWS AMI’s(Amazon Machine Image) provides the information like operating system, application server, and applications to launch into the virtual server(or can be called as an instance) in the cloud. There are lots of options for selecting AMIs provided by AWS or by the community. You can choose the preferred AMI that can meet your requirements. You can customize the instance that you have launched from the AMIs provided by AWS and can create your own AMI from that.All the AMIs created by you are private by default.

Interestingly the instances launched with Public AMIs in AWS comes with default user-name and no password authenticated which sometimes I don’t like. For example, Instances launched with Amazon Linux will have default user-name ec2-user and for Ubuntu instance default user-name is Ubuntu.

Instance launched with Public AMIs also does not allow you change the hostname on flight using user-data. Hostname for any instance launched with Public AMI looks something like


Example: ip-172-1-20-201

So I have decided to create an AMI which will have default user as Naveen and password as *****. And I would like to have my instance named as i.e hostname. I will use a cloud config script to do that.

cloud-init is a multi-distribution package that handles early initialization of cloud instances.More information can be found at Cloud-Init. Some of the tasks performed by cloud-init are

  • Set hostname
  • Set the default Locale (default user)
  • Generate host private ssh keys
  • Parse and handle user-data

Custom AMI

For creating my Custom AMI with above-mentioned changes I have followed the below steps:

1. I have launched a t2.micro instance with Amazon Linux AMI ‘ami-4fffc834’. You can launch the instance using AWS management console or be using AWS command line(aws-cli). I have used the aws-cli to launch the instance.

aws ec2 run-instances --image-id ami-4fffc834 --count 1 --instance-type t2.micro --key-name Naveen

The above command will launch one t2.micro instance with the key name ‘Naveen’.

2.  As I have launched the instance using Amazon Linux, the default user-name is ec2-user. Amazon Linux does setting default user using cloud-init. The configuration file for setting default user can be found in /etc/cloud/cloud.cfg.d/00_default.cfg. The config file looks something like below

# This will affect which distro class gets used
distro: amazon
distro_short: amzn
# Default user name + that default users groups (if added/used)
name: ec2-user
lock_passwd: true
gecos: EC2 Default User
groups: [ wheel ]
sudo: [ "ALL=(ALL) NOPASSWD:ALL" ]
shell: /bin/bash
# Other config here will be given to the distro class and/or path classes
cloud_dir: /var/lib/cloud/
templates_dir: /etc/cloud/templates/
upstart_dir: /etc/init/
- arches: [ i386, x86_64 ]
- repo.%(ec2_region)s.%(services_domain)s
- repo.%(ec2_region)
ssh_svcname: sshd


The 00_default.cfg contains other things as well but I have posted only the one which needed to be changed. As we can see the default username for this distro is ec2-user. lock_passwd: true means the user who is trying to log in with the username ec2-user is not allowed to authenticate using a password.

3. I have changed the user-name to Naveen and lock_passwd: false in the config file. But this config file does not allow entering the normal password as part of the config file. You need to give the password for the user in the hash. So to do that I have used the following commands in Ubuntu machine

# mkpasswd comes with whois package
 sudo ap-get install whois

#To Generate hash using mkpasswd mkpasswd –method=SHA-512 #This will prompt to enter password #After entering password, mkpasswd will generate hash and output on console Ex:  $6$G0Vu5qLWx4cZSHBx$0VYLSoIQxpLKVhlU.oBJdVSW7Ellswerdf.r/ZqWRuijiyTjPAXJzeGwYe1D/f94tt/tf

Copy the above-generated hash and add it to ‘passwd’ key in the above config file. After making final changes in the config file

system_info:   # This will affect which distro class gets used   distro: amazon   distro_short: amzn   # Default user name + that default users groups (if added/used)   default_user:     name: Naveen     lock_passwd: false     passwd: $6$G0Vu5qLWx4cZSHBx$0VYLSoIQxpLKVhlU.oBJdVSW7Elwerfwq.r/ZqWRuijiyTjPAXJzeGwYe1D/f94tt/tf1lXQYJtMtQLpvAqE1     gecos: Modified Default User name     groups: [ wheel ]     sudo: [ “ALL=(ALL:ALL) ALL” ]     shell: /bin/bash   # Other config here will be given to the distro class and/or path classes   paths:     cloud_dir: /var/lib/cloud/     templates_dir: /etc/cloud/templates/     upstart_dir: /etc/init/   package_mirrors:     – arches: [ i386, x86_64 ]       search:         regional:           – repo.%(ec2_region)s.%(services_domain)s           – repo.%(ec2_region)   ssh_svcname: sshd

4. Finally, i have made the following changes in rc.local which will change the behavior of ssh service to accept password authentication. And change the preserve_hostname to false in /etc/cloud.cfg

if grep -Fxq “PasswordAuthentication no” /etc/ssh/sshd_config then  sed -i ‘s/^PasswordAuthentication.*/PasswordAuthentication yes/’ /etc/ssh/sshd_config  /etc/init.d/sshd restart fi

With these changes above I have achieved adding default user-name with Naveen and with the default password. With changes above to the instance above I have created an AMI from the instance using aws-cli

aws ec2 create-image --instance-id i-09ebf4e320b0cadca --name "ONE_AMI"

    "ImageId": "ami-ebec0c91"

#Cloud-config for setting hostname

With the Customized i can launch the instance with user-name Naveen but still, the hostname will be in the format like IP-<Private-IPv4>. So  I have used the below cloud-config script to change the hostname.

#set the hostmachine name
#Add additional users for the machine
 - name: sysadmin
   groups: [root,wheel]
   passwd: $6$G0Vu5qLWx4cZSHBx$0VYLSoIQxpLKVhlU.oBJdVSW7EllsvFybq.r/ZqWRuijiyTjPAXJzeGwYe1D/f94tt/tf1lXQYJtMtQLpvAqE1
   sudo: ALL=(ALL:ALL) ALL   
#Final Message
final_message: "The system is finally up xcvxxxxxxxxxxxccccccccccccccccccccccc, after $UPTIME seconds"

The above script will create the instance with hostname and create a user sysadmin. The above script will be passed as part of user-data when launching an instance

aws ec2 run-instance --image-id ami-4240a138 --count 1 --intance-type t2.micro --user-data file://cloud.cfg

The above launch an instance without Key pair which means I can only log into the instance using the default user Naveen or using a username we have created in cloud configuration script that was passed a user-data.

Finally with this i have the instance with my custom default user-name and password, and a hostname with


Run on AWS – How to better control cloud…

AWS offers an innovative cloud platform that enables organizations to quickly build great apps at reduced costs. However, organizations that move their infrastructure to the AWS cloud should ensure that the architecture is optimally designed for AWS to make the most out of the agility and elasticity offered by AWS. Failing to do so negates the benefits offered by the cloud. Moreover, failing to choose the right tools for the right procedures across the organization would rise up the operational costs in quick time. Here are certain things to consider while building applications in the AWS cloud.

Optimized resource usage

In a traditional environment, businesses operate with a fixed infrastructure. As the infrastructure is installed up front, expensive hardware might be idle at some times. AWS offers a pay-as-you-go service wherein you can provision resources based on changing business needs. In addition to the compute resources, you can provision storage, database, and other high-level application components.  Scaling can be done in two ways; vertical scaling and horizontal scaling. For vertical scaling, you upgrade the configuration so that the system supports extra load. Horizontal scaling is where you add more components such as hard drives to an array.

In addition to scaling, you should consider stateless and stateful components. Stateless applications don’t store session information. It means the application provides the same information for any user at any time. For stateless components, you can add resources easily. Stateful components, on the other hand, store session information. Databases require stateful components. As a real-time example, e-commerce sites should store the user information so that they can offer customized prices. Similarly, most apps require sign-in from a user so that the personalized dashboard is offered to that user.

Choosing the right services

AWS offers more than 90 services. So, choosing the right services for right tasks is the key. For computing resources, you can choose Amazon Elastic Compute Cloud (Amazon EC2). Amazon Machine Image (AMI) can be used to recreate the configurational instances at any time. For storage purpose, you have Amazon Elastic Block Store (EBS). Snapshots of EBS are stored in Amazon S3. Amazon RDS enables you to store and manage data. Similarly, Amazon CloudFormation offers an on-demand IDE environment to develop code on the go. Amazon VPC is the virtual private cloud that allows you to securely extend your private network to the cloud. Organizations that process large volumes of data should go for a distributed processing system such as Amazon SQS, Amazon Kinesis. Apache Kafka is another option for processing streaming data. To reduce latency for global users, you can use Amazon CloudFront content delivery network.

Docker is a popular concept that allows developers to build and deploy applications inside a software container. Amazon offers AWS Elastic Beanstalk and Amazon ECS that allows you to build and deploy multiple Docker containers across multiple EC2 instances. Using Amazon CloudWatch, you can monitor and manage AWS cloud resources from a centralized dashboard.

Amazon offers four trusted advisor services at free of cost. These services allow you to monitor the performance, reliability, and security of your network. In addition, they help you in optimizing resource usage on AWS.

Securing your AWS infrastructure

Your AWS account is the key that opens up a whole new world of cloud networks. So, using the root account credentials for regular activities is not a good idea. Instead, you can create one or more IAM users who can interact with AWS for daily activities. Secondly, providing privileged based access to your AWS networks is recommended. You can distribute services among different groups and provide access to secure processes only to a defined range of IP addresses so that the outside traffic is denied access to those processes.

Having a proper backup and recovery plan is the key. Backup instances using EBS or a 3rd party backup tool and ensure that your recovery plan offers business continuity. Critical application components can be deployed across multiple time zones so that they can be replicated accordingly.

At the outset, AWS looks easy and pretty straightforward to use. However, without proper knowledge of the system, you can run into huge expenses. This is where CloudTern comes to the rescue. CloudTern AWS Managed Services provides customized software solutions tailored-made for your organization. With CloudTern Managed Services, you can better control cloud costs, improve operational efficiencies while securely processing your applications. Most importantly, you can concentrate on your core business processes while we take care of your cloud.


Create AWS AMI with custom SSH username and password


EC2 instance that is launched with Amazon Linux AMI will come up with ec2-user and you can only SSH into that instance with Private Key.


We wanted an Amazon Linux AMI (Base Image) with default username (similar to ec2-user) and that should allow SSH login with a password.

SSH login with a password is also a requirement for authenticating user login with OpenLDAP Server. That way our IT Operations need not remember new login information.  They can use their existing logins.


  1. Launch Amazon Linux AMI micro instance.
  2. Connect to instance with private key
  3. Create SSH User and give sudo permission  (similar to ec2-user)
    1. sudo useradd -s /bin/bash -m -d /home/<ssh-user-home-directory> -g root <ssh-user-name>
    2. sudo passwd <ssh-user-name>
  4. Enable Password login for SSH (add following snippet of code at the end of /etc/rc.local file)

           if grep -Fxq “PasswordAuthentication no” /etc/ssh/sshd_config 


                   #This instance launched for this first time, pleae enable SSH with password login

                    sed -i ‘s/^PasswordAuthentication.*/PasswordAuthentication yes/’ /etc/ssh/sshd_config

                    /etc/init.d/sshd restart


           This piece of code will change PasswordAuthentication to yes in sshd_config file. (If we don’t do       this every time we create Instance with AMI that will overwrite sshd_config file)

  1. Stop the instance
  2. Select Instance and create Image
  3. Now launch Instance with above created AMI.
  4. After Instance is launched you can log in with ssh username you have created in step 3.

Path to the AWS Cloud


You’ve heard of software as a service (SaaS), and Infrastructure as a Service, Platform as a Service, There is XaaS to describe Anything as a Service.  Now you can provide all of your company’s functions “as a Service” – Your Company as a Service (YCaaS).  You will be more scalable, more available, more connected to employees and customers, as well as suppliers.  Just hop on this cloud…

This blog is written to simplify your trip to the cloud.  It is written as a general-purpose document and specific details will vary with your needs.  This guide is written for migration to the AWS Cloud Platform. You will need an AWS account to begin this migration.  The result will be a very flexible and highly available platform that will host services for internal or external use.  Services may be turned up or discontinued, temporarily or permanently, very easily.  Services may be scaled up or down automatically to meet demands.  Because AWS services are billed as a service, computing services become operational rather than a capital expense (CAPEX).

The Framework

Exact needs will vary based on the services being migrated to the AWS Cloud.  The benefits of a structured, reliable framework will transform your organization’s approach to planning and be offering online services.  The AWS CAF (Cloud Adoption Framework) offers a structure for developing efficient and effective plans for cloud migration.  With guidance and best practices available within that framework, you will build a comprehensive approach to cloud computing across your organization.


Using the Framework (AWS CAF) to break down complicated plans into simple areas of focus, will speed the migration and improve success.  People, process, and technology are represented at the top level.  The components of the focus areas include:

  • Value (ROI)
  • People (Roles)
  • Priority and Control
  • Applications and Infrastructure
  • Risk and Compliance
  • Operations

Value, or Return on Investment, measure the monetary impact on your business.  For customer facing services, this could mean reaching more customers faster.  Customer engagement and meaningful transactions.  For internal services, ease of access and pertinence of content adds value.

People occupy many roles.  Organizationally, internal stakeholders will need to be involved in decision making and in ongoing support.  Business applications’ stakeholders have outcomes which they own in the planning stages and in the long term utilization. The content provider will have initial and ongoing responsibilities.  The end user is dependent on the platform and the other stakeholders.

Priority and control of the service are defined with the resources dedicated to the service migration and allowable disruption.  Priorities are affected by readiness.  New services are often easier to migrate due to the compatibility of platforms.  These may be migrated quickly ahead of more cumbersome services.  Mission critical services will require the resources and special attention that goes with critical status.

Risk and compliance are defined by the category of the usage of the service.  Commerce with external entities will demand PCI compliance.  Personal information of internal entities will demand HIPPA compliance.  CRM and general information will need copyright identification.

Operations are involved in the migration phase as the process of service migration affects business operations.   Because migration is not a day to day business process, it will require its own resources, planning, and priorities.  These priorities affect the resources available for the migration.  A fast migration may require more resources, people, bandwidth, communications.  Lower priority allows for fewer resources and, typically, less disruption.

Migration process

Migration is a process that will ride on top of the normal business process.  In order to successfully migrate to the cloud, all of these considerations will affect planning.  Given priorities that are decided upon, identify the people and roles that will be involved in the migration.  Communicate the specific outcomes the team will be responsible for.  Be specific, gain agreement and ownership.  Deliver the resources that the team identifies as needed to meet goals.  This includes time.  If the team has to be away from normal day to day responsibilities business process must be temporarily re-routed.  This will involve support teams one level removed from the migration.

Outsourced teams can provide temporary resources in highly specialized roles to reduce the impact on business operations.  Do the initial planning to determine your needs.  Choose an outsourced team based on experience in the specific roles you will need to fill.  Integrate the imported resources with appropriate internal team members.  Give ownership to the internal team and empower them to act when needs arise.

Construct the entire migration model before beginning the process.  Build the budget and prepare for the impact of resource dedication up front.  Measure progress against the model on weekly basis.  Communicate to the team that adjustments will be needed, and communication is the way these adjustments are dealt with.  Remember the butterfly effect: every change will result in cascading consequences.  With reliable communications, everyone will be more comfortable with the temporary effects of this over the top process.

When the team and their roles are communicated, the non-human resources can be quantified.  How much bandwidth will be required to meet identified goals?  Is the network capable of delivering on the required bandwidth, or will infrastructure need to be upgraded?  Consider the impact on infrastructure on critical business services that may occur during the migration.  Be prepared for contingencies and unexpected demands.

If network augmentation is required, how deep into your infrastructure will you need to adjust.  As data migration paths are identified and bandwidth is dedicated, will other segments of the network be affected?  These network augmentations have power and space impacts. Downstream, there will be additional people affected as configurations and replacement equipment are implemented.

Peak demand capacity is often a separate planning impact.  Peak busy hours will result in oversubscription of available bandwidth.  With oversubscription, will come service impact.  The impact is easily underestimated because saturation will lengthen the impact duration.  Along with the capacity planning, there needs to be service level consideration.  What tolerance to latency will the user base have?

Availability planning during migration will determine impact in the event of the disaster.  Business continuity plans may need to be modified during the migration period.  Existing failover functions will not include the migration paths.  If not addressed in advance, an unplanned outage will disrupt your migration and likely have a negative business impact.  Whatever availabilities are associated with your services which are migrating will need planning for the migration.

The cost of maintaining duplicate services during migration include licensing.  When two systems are running simultaneously, the license expense is double.  Depending on demand, and with planning, some efficiencies may keep this cost under the maximum.  While this may be an opportunity to eliminate some marginally needed or legacy expenses.

In the long run, you will reap the rewards.  Savings include the server maintenance, break-fix, and upgrades, backups, both local and off-site, environmental conditioning maintenance, power savings.  People time involved with the maintenance, break-fix, upgrades, and the bill paying for these services.  Importantly, scalability in the AWS cloud does not require as much advanced planning, over capacity implementation and over provisioning for future expansion.  Capacity can be reduced on the fly as well.

The total return on investment will include a cost increase during planning and migration and long-term savings due to increased efficiencies and cost reductions.   The total cost of ownership grows over time, but will not include associated direct and indirect costs.  Intangible return is in technology upgrades.  The obsoleting of capital investments will greatly decrease.  Technology will evolve and be implemented invisibly for immediate use in the cloud platform.   



Pin It on Pinterest