How to Automatically Scale Up Your Application on AWS ?

This basic rule is you have to make your application servers and databases to be independent of each other. The application servers are only responsible for processing game or business logic without saving any cache data at local. The databases are used for saving game or user data. In front of the application servers, it is necessary to set up a load balancer - while there is any problem occurring to make a server become unavailable - to redirect the user traffic to available servers.  

Moreover, if you want to reduce the overhead of MYSQL such as the number of current connections to improve performance, you can use shared memory servers like Redis or Memcached to save user sessions to decrease the number of SQL queries on MYSQL.

In addition, NoSQL database, Couchbase or MongoDB, would be a better alternative to replace MYSQL database. It can dramatically improve the performance of web applications.

As the user traffic grows, you can easily add one EC2 application server on AWS or  improve MYSQL/NoSQL database specs to meet this need.  

The proposed methods below will teach you how to set up an auto-scale
infrastructure for your applications. 

1.Create StartApp Script for Java Application/Tomcat  at startup time

Initial an EC2 instance and deploy your Java Application on this EC2 and set up a startApp script below at startup time. 
vim startapp

#!/bin/bash
cd /home/weishihhsun/app/
nohup java -jar p2pServer.jar &

sudo cp startapp /etc/init.d
sudo chmod +x /etc/init.d/startapp
sudo update-rc.d startapp defaults 98 02

98 and 02 are the start and stop sequence numbers respectively.
Both are numbers between 00 and 99 and specify how early or late a service is started or killed

By doing so, your Java or Tomcat application would be booted up at startup time.

2. Create an image of EC2 instance on AWS

You need to create an image of EC instance - a clone of this server - by AWS Control UI.    

3. Setup Auto-Scaling Group

You need to add an image of EC2 instance to the auto-scaling group and set up some thresholds to trigger different types of alarms, such as the usage of CPU, hard disk, and internet traffic. 

The usage of CPU, for example, is more than 80%, then automatically increase the EC2 instance of a server; if it is below 10%, then decrease the EC2 instance of  a server.

To conclude, you have learned how to build a high availability and scalability infrastructure for your applications. By making use of the proposed methods, you can automatically scale up your application servers developed by PHP, Java, C# or C/C++ on AWS, as long as you make your applications independent of the database.

How to secure REST API ?

I recommend you implement the protocol of OAuth 2.0 to secure your REST API because the spec of OAuth 2.0 shows that the authorization server must require the use of TLS when sending requests using password authorization as shown below.

HTTP Basic Authorization Request Message:
POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
     &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

Client_id        : Client Account
Client_secret :  Client Password

If you don`t implement TLS/SSL, your plaintext of account and password might be intercepted by Man In Middle Attack.

On the other hand, OAuth 1.0 shows that TLS is must feature to secure your plaintext but did not mention in detail what version of TLS should be adapted or who should implement it

Therefore I propose three methods outlined below to pretend your REST API.

1. Must Use SSL/TLS
You must implement the TLS/SSL before sending the plaintext of password and account to Authorization Server. By doing so, your plaintext would be less vulnerable to being intercepted.

In addition, for telecom application services, they also implement TLS to secure SIP - they set up a secure channel by TLS between the client and the server first and do HTTP Basic Digest Authentication, then start to make, answer or transfer the call in SIP over this secure channel. This is why TLS/SSL is widely used to secure communication layers in the different industry, such as game, telecom, and e-commerce.

2. Shorten the lifetime of a token key
After finishing the authorization, the client will get the access token with the lifetime. You can shorten the lifetime to reduce the risk of a token being hijacked.

3. Implement Your asymmetric encryption algorithm to encrypt plain text values of account and password

What if one day the TLS/SSL becomes not secure, the same situation will happen again that you   must implement your mechanism to encrypt your plaintext of account and password.

Take RSA for example, you can implement the method as shown below.

 Public and private key are generated by your server. You can give the public key to the client in private.

 1. Client :
  tokenUserId = encryption (useId::random key, publicKey)
  tokenPassword = encryption (Password::random key, publicKey)

 The client encrypts the values of userId and Password by public Key and random key and sends  tokenUserId and  tokenPassword to the server.
 The random key could be generated by time stamp or any mechanism you prefer.

  2.Server :
  UserId = decryption (tokenUserId, privateKey)
  Password = decryption (tokenPassword, privateKey)

  The server decrypts those encrypted tokens - tokenUserId and tokenPassword  - with the private key   and starts to do HTTP Basic Authorization.

  Of course, you can use any asymmetric encryption algorithm you like.

 To conclude, the safest method to secure your important data sent over the internet is  using proprietary protocol - Skype, What`s app, Line, for example, all have implemented  their proprietary encryption and decryption algorithms to make the data more secure instead of  following the standard. Perpahs cracking a proprietary protocol is harder than the standard one.  

  Reference :
  RFC 5849 The OAuth 1.0 Protocol
  RFC 6749 The OAuth 2.0 Authorization Framework
  RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
  RFC 5630  The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)