A lot of mobile related start-ups have mushroomed over the past few years. All these companies start with a conviction that theirs is going to be next big idea. There is faith that the start-up is going to see rapid and significant demand, or at least calculations in Excel say so.

This inherent belief of next big demand requires that all pieces of operations and technology also need to scale. The challenge, typically, is that this expected growth is generally unquantifiable. The question that needs to be addressed from a technology perspective is how many resources you commit up front when every penny counts to start operations.

The unquantifiable demand, which could go up and down, should be backed by resources that expand and contract as per demand. No points for guessing that I am going to suggest the cloud as the solution.

In this article, I want to put down a template infrastructure for our typical mobile start-ups and how they can leverage AWS to meet their unquantifiable demands.

Let us look at the AWS template below. I have numbered various components to help you understand how that component caters to the concerns of the start-up.

1. Scale to Meet Demand and Self-Healing

Amazon CloudFront:  Amazon has data centers worldwide called edge locations. The app user is routed to the nearest edge location. Start-ups should consider delivering all static content via CloudFront. In a simplified world, the company can keep all its content in S3 buckets. CloudFront would read and cache content in various regions

Lambda (serverless compute): The code is executed only when it is needed and scales automatically. The best part is that you pay only for compute time used. There is no charge when you are not running your code. Lambda can be invoked through events coming in from API Gateway. Start-ups can expose REST endpoints on API Gateway that are internally mapped to Lambda.

Autoscale servers: Autoscaling, combined with CloudWatch, allows the application infrastructure to dynamically increase in number. A small tip to avoid session stickiness at the load balancer is to configure servers to maintain sessions in AWS DynamoDB. This allows every request to be served by any server with the session state readily available.

2. Disaster Recovery

Disaster can strike any system, irrespective of the size and scale of the company. Hence, there is the need to plan. The decision point really is on two counts (a) RTO – recovery time objective, and (b) RPO – recovery point objective. The time objective defines how much time before normal operations are restored. The point objective is really up to what point the system is restored.

There are spectrum of options to disaster recovery with cost increasing from left to right.  At the same time RTO and RPO also get better from left to right.

In my view at bare minimum, the startup must maintain a backup database in a different data center. With AWS RDS Multi-AZ (availability zone) options, AWS automatically replicates data to a standby instance in a different availability zone. In the event of failure, automatic failover to a standby database happens.

3. User Management (Sign-In, Sign-up, Activate)

All mobile apps have the basic need to do user sign-up and sign-in. AWS Cognito is a tailor-made solution for such requirements. This piece can save a lot of boilerplate functionality. Cognito allows login via user pools created through apps — or if you want to do social logins via Google or Facebook. Or even more if you want to integrate corporate users via SAML. User confirmations can be configured over links sent via emails or even SMS messages sent to phones. User authentication is done very securely using the SRP (Secure Remote Password) protocol.

4. Send Notifications

AWS SNS allows you to reliably send messages to a large number of subscribers. You can send push notifications to Android, iOS etc.

5. High Performance and Throughput Data Access Layer

RDS (relational database service): AWS RDS is a managed relational database service. You don’t need specialized DBA skills in your startup to run and manage your database. You can easily scale your database compute power by changing the instance type and also create read replicas to scale reads in a matter of few clicks.

Elasticache (Redis): AWS allows the quick setup of caching for your app. The Redis cache is easily scalable with up to 16 shards. Each shard in itself is highly available through a master-slave setup. The cache can be kept in front of the database, and a caching strategy for SQL queries can be chosen. This could be storage of CachedRowSets or serialized objects that are directly usable in the app. SQL queries can be used as keys to get the value. 

Load distribution: AWS load balancers are easily configurable and can reliably send traffic to healthy app servers. The load balancer itself scales to meet the demand of application traffic. Also, it integrates with autoscaling to ensure that more app server instances come up without manual intervention

6. Secure Access to Environment

AWS IAM provides secure access to all this environment set up. The free culture of young start-ups needs that kind of control when production access procedures have not yet matured.

7. Archival Strategy

AWS provides Glacier for retaining content for the long-term. You can create lifecycle events on content, which would eventually move to Glacier in, for example, 6 months. The cost of storing stuff in Glacier is pretty low.

In addition to all this, AWS allows you to manage multiple environments based on this blueprint architecture. You can codify this architecture in Cloud Formation templates. These templates could then be used to stand up multiple environments of development, user acceptance testing etc.

There are many more services that AWS offers. My endeavor was to show you a practical AWS architecture that any mobile startup on a LAMP stack could easily migrate to.