Introduction

We will go through step by step hands-on scenario to build virtual appliance for SAP HANA on AWS in this hands-on. It includes how to install SAP HANA on AWS and we will go through the steps required to install and configure SAP HANA on AWS. I hope the information contained in this hands-on provide you basic idea about what AWS services are and how to configure SAP HANA on AWS environment.

The hands-on is composed of following posts:

1. Prior knowledge
2. EC2 instance creation
3. EC2 instance configuration
4. SAP HANA installation for the master
5. Adding worker to SAP HANA landscape.

This post handles the second part of the hands-on.

We will try most steps in command line (awscli) but you should know that all tasks in this hands-on could be done on AWS console too.

2. EC2 instance creation

We will create a EC2 instance where SAP HANA instance will live. This chapter is highly referring to below links:

• https://d1.awsstatic.com/enterprise-marketing/SAP/SAP-HANA-on-AWS-Manual-Setup-Guide.pdf
• All scripts from https://github.com/aws-quickstart/quickstart-sap-hana
• https://docs.aws.amazon.com/quickstart/latest/sap-hana/welcome.html

We have to prepare some information before going to create new EC2 instance. That’s explained through the next few sections.

2.1. Planning subnet

We will define new subnet (or we can use existing subnet too) for new EC2 instances.

2.1.1. Find your VPC CIDR

Subnet will be created in VPC (or you can use the existing subnet). You can find the current VPC information (VpcId and CidrBlock) with below command:

yourLinux:~ # aws ec2 describe-vpcs
{
    "Vpcs": [
        {
            "VpcId": "vpc-b49ab4dc",
            "InstanceTenancy": "default",
            "CidrBlockAssociationSet": [
                {
                    "AssociationId": "vpc-cidr-assoc-c3d368ab",
                    "CidrBlock": "172.31.0.0/16",
                    "CidrBlockState": {
                        "State": "associated"
                    }
                }
            ],
            "State": "available",
            "DhcpOptionsId": "dopt-960819fe",
            "CidrBlock": "172.31.0.0/16",
            "IsDefault": true
        }
    ]
}

2.1.2. Create your subnet

For this task, we have to choose the correct availability zone in the current region first. We can find usable availability zones within the region:

yourLinux:~ # aws ec2 describe-availability-zones --region ap-northeast-2
{
    "AvailabilityZones": [
        {
            "State": "available",
            "ZoneName": "ap-northeast-2a",
            "Messages": [],
            "RegionName": "ap-northeast-2"
        },
        {
            "State": "available",
            "ZoneName": "ap-northeast-2c",
            "Messages": [],
            "RegionName": "ap-northeast-2"
        }
    ]
}

You can choose any name among a couple of availability zone names displayed, for example, ap-northeast-2c in this hands-on.

We will create a subnet by splitting CidrBlock of VpcId. It’s done by adding more bits to VPC CIDR and specifying different network IP address. In this example, I add just one more bit to VPC CIDR block to create a new subnet. That is, VPC CIDR is 172.31.0.0/16 (10101100. 00011111.), and I will use 172.31.128.0/17 (10101100. 00011111.1) for new subnet.

yourLinux:~ # aws ec2 create-subnet --vpc-id vpc-b49ab4dc --cidr-block 172.31.128.0/17 --availability-zone ap-northeast-2c
{
    "Subnet": {
        "AvailabilityZone": "ap-northeast-2c",
        "AvailableIpAddressCount": 32763,
        "DefaultForAz": false,
        "Ipv6CidrBlockAssociationSet": [],
        "VpcId": "vpc-b49ab4dc",
        "State": "pending",
        "MapPublicIpOnLaunch": false,
        "SubnetId": "subnet-0ec93994701de0193",
        "CidrBlock": "172.31.128.0/17",
        "AssignIpv6AddressOnCreation": false
    }
}

You need to check if the new subnet becomes available with “aws ec2 describe-subnets” command.

yourLinux:~ # aws ec2 describe-subnets
{
    "Subnet": {
        "AvailabilityZone": "ap-northeast-2c",
        "AvailableIpAddressCount": 32763,
        "DefaultForAz": false,
        "Ipv6CidrBlockAssociationSet": [],
        "VpcId": "vpc-b49ab4dc",
        "State": "available",
        "MapPublicIpOnLaunch": false,
        "SubnetId": "subnet-0ec93994701de0193",
        "CidrBlock": "172.31.128.0/17",
        "AssignIpv6AddressOnCreation": false
    }
}

You will find SubnetId and CidrBlock in the output.

Now, you get to know where EC2 instance will be located, which VPC, which Availability Zone and which subnet in VPC.

Once subnet is decided, you can define EC2 instance’s private IP address within the subnet. For example, 172.31.128.21/17.

Memo.

How many IP addresses are available for 172.31.128.0/17 ?

• Last 15 bits will be used for Host IP address, that is, 32767 (7FFF) IP addresses.
• One IP address, 171.31.255.255, is reserved for broadcast IP address).
• Another three IP addresses (172.31.128.1, 172.31.128.2, 172.31.128.3) are reserved for AWS use.
• That is, 32767 -4 = 32763 IP addresses are available.

2.2. Choose an AMI

Next, we will choose Amazon Machine Image (AMI) to be used for our EC2 instance.

The AMIs listed in above table are based on https://github.com/aws-quickstart/quickstart-sap-netweaver-abap/blob/master/templates/sap-netweaver-hana-abap.template.

AMIs from each region has different AMI ID (ImageId in above table). ImageId in this table is for “ap-northeast-2” region because this hands-on is done in the region. If you are in different region than “ap-northeast-2”, you have to find the ImageId matching to your region. You can find an ImageId with “aws ec2 describe-images …” command:

yourLinux:~ # aws ec2 describe-images --owners self amazon aws-marketplace  --filters "Name=name, Values=suse-sles-12-sp3-v20180215-hvm-ssd-x86_64"
{
    "Images": [
        {
            "VirtualizationType": "hvm",
            "Description": "SUSE Linux Enterprise Server 12 SP3 (HVM, 64-bit, SSD-Backed)",
            "Hypervisor": "xen",
            "ImageOwnerAlias": "amazon",
            "EnaSupport": true,
            "SriovNetSupport": "simple",
            "ImageId": "ami-e22b898c",
            "State": "available",
            "BlockDeviceMappings": [
                {
                    "DeviceName": "/dev/sda1",
                    "Ebs": {
                        "Encrypted": false,
                        "DeleteOnTermination": true,
                        "VolumeType": "gp2",
                        "VolumeSize": 10,
                        "SnapshotId": "snap-07d6aad627cbd5fe3"
                    }
                }
            ],
            "Architecture": "x86_64",
            "ImageLocation": "amazon/suse-sles-12-sp3-v20180215-hvm-ssd-x86_64",
            "RootDeviceType": "ebs",
            "OwnerId": "013907871322",
            "RootDeviceName": "/dev/sda1",
            "CreationDate": "2018-02-15T14:54:50.000Z",
            "Public": true,
            "ImageType": "machine",
            "Name": "suse-sles-12-sp3-v20180215-hvm-ssd-x86_64"
        }
    ]
}

We get ImageId of the AMI, which is for “suse-sles-12-sp3-v20180215-hvm-ssd-x86_64” in “ap-northeast-2” region.

I will use this AMI (ami-e22b898c). All steps in this hands-on are for “suse-sles-12-sp3”. You need to find AMI in your region with the name “suse-sles-12-sp3-v20180215-hvm-ssd-x86_64”.

We can go to next steps for choosing instance type.

2.3. Choose an EC2 instance type

“Instance types” define combinations of vCPU, memory, storage, network performance (capacity). You can choose a mix of resources for your applications or databases.

Usually following instance types are considered for high-performance databases, in-memory databases and other memory intensive enterprise applications. It’s started with “x” or “r”.

Excerpt from https://aws.amazon.com/ec2/instance-types/

Memo.

Minimum 24 GB memory is required to install SAP HANA. So r4.large is NOT eligible for SAP HANA installation.

For your reference,

• The first character means the purpose of the instance:

“t or m” : for general purpose.

“c” : for compute oriented

“r or x” : for memory optimized.

“p or g” : for accelerated computing.

“d or h or I” : for storage optimized.

• The second character means the generation of the instance type (the higher, the newer).

• Large, xlarge, 2xlarge, …. is the instance size. It increases double in every aspect including the capacity and price rate on demand, etc.

Memo.

You may meet an error “Client.Unsupported: The requested configuration is currently not supported”. This means the instance type is not supported in your Availability Zone.

You can check which instance types are supported in your region / availability zone with “aws ec2 describe-reserved-instances-offerings” command, for example,

# aws ec2 describe-reserved-instances-offerings --filters "Name=availability-zone,Values=ap-northeast-2c" --region ap-northeast-2

In this hands-on, I choose r4.2xlarge for simple configuration test. r4.2xlarge will provide 8 vCPUs, 61 GB memory, EBS as a storage type.

2.4. Configure instance details

You need to decide more on instance details in addition to AMI and instance type:

• “Number of Instances” means how many instances you want to create. You can specify value larger than or equal to 1. In case you want to configure scale-out landscape, you may specify 2, 3, etc. We will use 1 for “Number of Instances” in this hands-on. You can create another instance later when scale-out requirement newly comes up.
• “Placement group”, AWS instances that exist within the same availability zone can be grouped into a placement group. Group members are able to communicate with one another in a way that provides low latency and high throughput. Placement group can be created using one of the two strategies, cluster or spread.
  • The original purpose of placement groups, being to co-locate instances to provide benefits such as low latency/high bandwidth networking, is still met by the ‘Cluster’ configuration.
  • The ‘Spread’ configuration though is a very different use case that essentially allows you to place instances far apart from each other to reduce the risk of common failures occurring on shared hardware.

Summarily, cluster strategy limits placement group to 1 Availability Zone, whereas the spread can span multiple Availability zones (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html).

We will create our own placement group so all instances are placed in it.

• With “Shutdown behavior”, you can specify the instance behavior when OS level shutdown performs. “stop” will only stop the instance but “terminate” will make an instance unusable anymore (instance will vanish and all objects will be terminated).
• “EBS-optimized instance” means that EBS-optimized instances deliver dedicated bandwidth to Amazon EBS, with options between 425 Mbps and 14,000 Mbps, depending on the instance type you will use. You can check below link to find if your instance is set EBS-optimized by default and what maximum bandwidth (Mbps) is: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/EBSOptimized.html
• When “Enable termination protection” is enabled, you cannot terminate the instance until you explicitly disable this option. This is for protecting instance from being accidentally terminated.

2.5. Prepare block device mappings

We need a storage for database files and backup, etc. We will obtain the storage from EBS (Elastic Block Storage).

We will add EBSes based on a couple of factors:

• Size estimation for database or other requirements.
• The strategy in volume creations, eg. Stripe for performance, etc.
• We will create one volume group for database files and backup (/hana/data, /hana/log, /hana/shared and /backup file systems). Using this volume group, we will create four logical volumes for four file systems and each logical volume will use four stripes.
• We will create a json file (eg. /tmp/ebs.json) using the following content, which will be used for allocating and attaching EBSes to EC2 instance while launching.

yourLinux:~ # cat /tmp/ebs.json
[
{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":100,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdf","Ebs":{"VolumeSize":667,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdg","Ebs":{"VolumeSize":667,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdh","Ebs":{"VolumeSize":667,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdi","Ebs":{"VolumeSize":667,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdj","Ebs":{"VolumeSize":50,"VolumeType":"gp2","DeleteOnTermination":true}},
{"DeviceName":"/dev/sdk","Ebs":{"VolumeSize":50,"VolumeType":"gp2","DeleteOnTermination":true}}
]

The above EBS configuration is under below idea:

1. Root file system will be 100 GB or so (“/dev/sda1” is used for “/” file system by default).
2. Database related file systems need more I/O throughput. We will create one volume group with four EBSes, total 2.6 TB. Four logical volumes will be created in this volume group for data(/hana/data), log(/hana/log), backup(/backup) and hana shared (/hana/shared) file systems. As you will see later, /hana/shared and /backup file systems will be shared between a master and a worker. This means that you don’t need to create backup(/backup) and hana shared (/hana/shared) file systems in workers.
3. We will create a file system (“/usr/sap”) for local SAP files. It only has database configuration and executable files, libraries and a link to /hana/shared file system with not much performance requirement, so we will use single EBS for this file system.
4. One more file system (/media) is required to keep SAP HANA installation media files. It’ll be used for installation purpose only and you are free to remove the file system and deallocate EBS once an installation is done on a master.All above considerations are dependent on your requirements. So, you may feel free to change the volume size or volume group configuration.

2.6. Configure security groups

A security group is for opening TCP/UDP ports for inbound and outbound communications.

We will create a security group and permit a few ports for inbound. For outbound communications from a master and a worker, we will open all ports.

yourLinux:~ # aws ec2 create-security-group --group-name SecGrp --description "SecGrp for test" --vpc-id vpc-b49ab4dc
{
    "GroupId": "sg-07d8b7d9bc71e0e5d"
}

We have to configure this security group for INBOUND and OUTBOUND. Normally OUTBOUND is allowed for all ports in TCP.

<INBOUND>

*) ## means SAP HANA instance number, eg. 00

*) PrivSubCIDR is for private subnet. In this hands-on, it’s 172.31.128.0/17

*) DMZCIDR is for DMZ network. We won’t configure DMZ in this hands-on and we use “0.0.0.0/0”.

*) In case you won’t be in MDC environment, you don’t need to open 3##13, 3##41-3##44.

<OUTBOUND>

If you mean to configure scale-out, INBOUND and OUTBOUND settings between EC2 master and EC2 worker instances will be different because Master and Workers have different communication requirements. For example, port 2049/udp (for NFS) should be opened in Master to export file system share, but it is not necessary to open in Workers. This means that we have to create two security groups, one for a master and the other for a worker, in production environments. But we’ll share one security group for own convenience in the hands-on.

For security protection, it makes sense to open the minimum number of ports to minimize security vulnerability.

The security group is created and we need to specify ports and protocols to be opened for INBOUND and OUTBOUND rules.

yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 22 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol udp --port 111 --cidr 172.31.128.0/17
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 1128-1129 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol udp --port 2049 --cidr 172.31.128.0/17
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol udp --port 4000-4002 --cidr 172.31.128.0/17
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 4300 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 8000 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 8080 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 8443 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 30015 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 30017 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 30041-30044 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 50013-50014 --cidr 0.0.0.0/0
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 1-65535 --cidr 172.31.128.0/17
yourLinux:~ # aws ec2 authorize-security-group-ingress --group-name SecGrp --protocol tcp --port 1-65535 --cidr 172.31.128.0/17
yourLinux:~ # aws ec2 authorize-security-group-egress --group-id sg-07d8b7d9bc71e0e5d --protocol=tcp --port 1-65535 --cidr=0.0.0.0/0

Memo.

You may notice that two subcommands are used, authorize-security-group-ingress and authorize-security-group-egress.

You may also notice that both group-name and group-id can be used in authorize-security-group-ingress, but only group-id is used in authorize-security-group-egress.

You can check the security group configuration:

yourLinux:~ # aws ec2 describe-security-groups –group-names SecGrp

2.7. Create key pair

A keypair is imperatively required in accessing EC2 instance. It has an extension PEM (Privacy Enhanced Mail). Public key is kept in EC2 instance and private key is written to a keypair PEM file while keypair is created.

yourLinux:~ # aws ec2 create-key-pair --key-name KeyPair --output text > KeyPair.pem

KeyPair.PEM file from above command needs a slight modification. You have to edit the file so the content looks like below. That means it should start with “—–BEGIN RSA PRIVATE KEY—–” and end with “—–END RSA PRIVATE KEY—–“:

Eg. KeyPair.pem

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAnCVxAiUH6u4fx8NcZMN7S0I+rcpMIyX2H+UaDBPcfPFOkmpmOyIO0jQFwGli
yob1F75szE+PtUdboKjGSCL9HzGpEl+pqIv09JqzGEW/5ogU7JVrELVT+5BffO2EGQo/RSqHVETr
VWPnukMXaV0zB9mz48IyXuxlKjiLvauFzI6H2374oXkPQk/oAQIbJJAxyMwBxa6PkOXRorQIZsMa
UTJ9DQkayV48e87/8XN6VQ8V9NpA3Hr1zZjRNuc0HdLYb6VVVSOKUz/oCE/+MGnP4MERtMfE8vzM
CrwkU22oF6W6aYOcrn/x67MrBudJVxow9r2APPeJzaQe09rqxdJlFwIDAQABAoIBAAVVpiG7oCSf
lAhgHUT4BLtSfQ+07Jr6zgjS6+vjtdGy8MtBxVJZ3IXD7zpen1hp+e+gutjUEwXPdUrs2TFXuKwb
JzqQeBxhA7JjoqC+qUq39XcLt8evWjoq+YgsGSo91mGHjW4MmLmnGyCa8C7SV076WhH67XueueoS
WnvVY1HUswHWTVc3UxmI1n6yxOT0TCNHxBkwC3sgze1eaqKeC3dw5xEo1z7Eud+xino/ebLzE4Oo
IZCqQCAalUKTsyntEAjF/QX9J4PGMrZo3Pg3Q6LiCISklMg3gNQ5iea6iG47i3utsZb9p+ZUF8nL
H3/VLlq3Ig9b9ueCMOERHI6/ZdECgYEA3+JlvqwgLqWE7LeR6WXXxcoB6pPH8IsZ3N7um/S5RnTa
EC9/RBHgYGX3prWz6lE4BJ7cXJ4xsIiO3oO+DuJ5ZtH0gDWisl/8Lut+XzGATEMmU329qaYdYXLG
dTQzgBSMB8dIMGC+J2OmbVlJysNkLNfWwv7fruSttrx3lq7q+OkCgYEAsouHT/dURI8UYeZkdtYF
7oB1UuJOXM1IHpeZD3xdgzKgoMRlFyIOiV8yrx/bAmriGviBPTh54z4Y/7dIC8cLA2oCCOuS9ywf
bDVzIrPhacI64goYAdOHXzDmdn6mEm3kytj6rYMChKxo4gzeLPITSyK7qPLbV0Ea8zWwNKm3rf8C
gYEA30ea0R44uky41Jv/GRZIqylb3+aicHNJx81Nipv2ax3+nEXCVtC9RWZsJgbw968ofvMwMe5T
AAww8BnTYmTbTn/1qCfVqq+vgdu6nJVxrp0JjBrLHHZetuEQq7Lz6biULu3AQP86pW3sfQGfZmiX
b2GS/cXSr0nBNY2gdtbb4IECgYBn7v0XubweJMQSsVEuNCxDyBeD5iUDtKQU2t7Iuvaclu4WZ/0I
2FRp9zbD5uFQqPNyC9L/1k5t0AoxYXnZEUcB98Wzd56Xr+Gi1gJt4xSGwgAQ8RtEhOQ6r3aY5+S4
uawDwQc71hWzMcHkROVYeJpulIt1L9orEsUjas9l+J3p9QKBgQCJrMhr9yfnPHQm5WtZzSVNm/zV
CZFjK/mW2TbS15RhgteE36enh4iQ+hY3sYulsoiJtoN4dkhvIu06wkr28WN3LG60weZYefm7tB2r
xSivSj6mmfjk5ZlF2ANSZVun5vNdvHyknfpyG8uvo867D/sXHj6DLnq8wWnLP0C/ehLWcg==
-----END RSA PRIVATE KEY-----

PEM file is used to connect to EC2 instance once EC2 instance is successfully launched.

Memo.

A key pair versus an access key:

• PEM file (key pair file) is for keeping private key to connect to the specific EC2 instance.

• Access key id and secret access key is for authenticating your account while accessing to AWS services.

Memo.

The keypair PEM file is required whenever you connect to EC2 instance. You should know where this keypair PEM file is downloaded or saved. In case it’s not in the current working directory, you have to specify the full file path on SSH command with “-i” option.

Memo.

For Windows, file redirection defaults to UTF-8 encoding, which cannot be used in some SSH clients. You must explicitly specify ASCII encoding in the out-file command(https://docs.aws.amazon.com/cli/latest/userguide/cli-ec2-keypairs.html).

C:\> aws ec2 create-key-pair --key-name KeyPair --output text | out-file -encoding ascii -filepath KeyPair.pem

2.8. Create placement group

You can create placement group with the following command:

yourLinux:~ # aws ec2 create-placement-group --group-name myplsgrp --strategy cluster

You can check the list of plancement groups:

yourLinux:~ # aws ec2 describe-placement-groups

2.9. Add tags

It’s an optional action to assign metadata or alias to AWS resources (eg. EC2 instance). You can simply put any tags for Instances and Volumes. We will add a tag as follows for EC2 instance to be created.

2.10.  Launch EC2 instance

Below table contains all checkpoint information in this hands-on. We’ve gathered the information or created some AWS objects if required:

You need to run the following command to launch your EC2 instance.

yourLinux:~ # aws ec2 run-instances  \
--image-id ami-e22b898c \
--count 1 \
--instance-type r4.2xlarge \
--ebs-optimized  \
--private-ip-address 172.31.128.21 \
--key-name=KeyPair \
--security-group-ids sg-07d8b7d9bc71e0e5d \
--subnet-id subnet-0ec93994701de0193 \
--placement AvailabilityZone=ap-northeast-2c,GroupName=myplsgrp \
--instance-initiated-shutdown-behavior stop \
--block-device-mappings file:///tmp/ebs.json \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=SAP HANA Master}]'

You can refer to “2.4. Configure Instance details”  regarding the options, –count, –ebs-optimized, –instance-initiated-shutdown-behavior.

You need to keep InstanceId from the output. In my case, it’s “i-0a8eb78dbab3d9353“ as below, for instance.

{
    "Instances": [
        {
            "Monitoring": {
                "State": "disabled"
            },
            "PublicDnsName": "",
            "StateReason": {
                "Message": "pending",
                "Code": "pending"
            },
            "State": {
                "Code": 0,
                "Name": "pending"
            },

            "InstanceId": "i-0a8eb78dbab3d9353",
            "ImageId": "ami-e22b898c",

}

You can check the status of EC2 instance by the command:

yourLinux:~ # aws ec2 describe-instance-status --instance-ids i-0a8eb78dbab3d9353
{
    "InstanceStatuses": [
        {
            "InstanceId": "i-0a8eb78dbab3d9353",
            "InstanceState": {
                "Code": 16,
                "Name": "running"
            },
            "AvailabilityZone": "ap-northeast-2c",
            "SystemStatus": {
                "Status": "ok",
                "Details": [
                    {
                        "Status": "passed",
                        "Name": "reachability"
                    }
                ]
            },
            "InstanceStatus": {
                "Status": "ok",
                "Details": [
                    {
                        "Status": "passed",
                        "Name": "reachability"
                    }
                ]
            }
        }
    ]
} 

You will need to check the status while running the command several times. We say that EC2 instance are ready when “InstanceState” is “running” and both “InstanceStatus” and “SystemStatus” change to “passed”.

2.11. Elastic IP address

We can connect to the newly created EC2 instance. Once EC2 instance is created, we need public IP address of EC2 instance. We have to go through two steps to allocate a public IP address using elastic IP address.

• Create elastic IP address.

yourLinux:~ # aws ec2 allocate-address
{
    "PublicIp": "52.78.39.220",
    "Domain": "vpc",
    "AllocationId": "eipalloc-043cfeff6c4e8c711"
}

•  Associate elastic IP address to instance’s private IP address.

yourLinux:~ # aws ec2 associate-address --instance-id i-0a8eb78dbab3d9353 --allocation-id eipalloc-043cfeff6c4e8c711
{
    "AssociationId": "eipassoc-0c8ec2f0d5122bfa5"
}

The elastic IP address is associated to EC2 instance. Any pre-existing public IP address is replaced with this elastic IP address.

The list of elastic IP addresses can be displayed with below command:

yourLinux:~ # aws ec2 describe-addresses
{
    "Addresses": [
        {
            "Domain": "vpc",
            "InstanceId": " i-0a8eb78dbab3d9353",
            "NetworkInterfaceId": "eni-0072c65d64864c809",
            "AssociationId": " eipassoc-0c8ec2f0d5122bfa5",
            "NetworkInterfaceOwnerId": "786447197291",
            "PublicIp": "52.78.39.220",
            "AllocationId": " eipalloc-043cfeff6c4e8c711",
            "PrivateIpAddress": "172.31.128.21"
        }
    ]
}

EC2 instance has been started and we can connect to this instance by the elastic IP address, 52.78.39.220.

We’ve done in “EC2 instance creation”. We have to move forward to setup the EC2 instance (https://blogs.sap.com/2018/07/04/hands-on-configure-sap-hana-on-aws-part3/).