Sie sind auf Seite 1von 20


Table of Content

Guide to Amazon Web Services

1 What is Infrastructure as a Service? 2 How to Determine if IaaS is right for you 2 IaaS may not be right for you if... 3 The Major IaaS Players 4 Pro Tips for IaaS Evaluation 5 5 Best Practices for Deploying an Application on AWS

Guide to Amazon Web Services

1 What is Infrastructure as a Service? 2 How to Determine if IaaS is right for you 2 How to determine if IaaS may not be right for you 3 The Major IaaS Players 4 Pro Tips for IaaS Evaluation 5 5 Best Practices for Deploying an Application on AWS

AWS Outage Survival Guide

6 Surviving AWS Failures with a Node.js & MongoDB Stack 10 Migrating from GoDaddy DNS to Amazon Route 53 11 Recovering from a DNS service outage in AWS using Monit

Chapte 1 Guide to Amazon Web Services


Welcome to the latest Kinvey eBook. We aim to help our community of developers keep pace with the latest trends in app development, tools and marketing. Typically we share our perspective on our blog, but when our audience is interested in a topic that cant be done justice in 500 words, we publish an eBook instead.

is perhaps the most fundamental of the categories. Before diving into our guide, lets rst review IaaS basics:

According to TechTarget, Infrastructure as a Service is a cloud-based provision model that services cloud storage, virtual servers and networking components to application owners for a usage-based cost. Its goal is to is to become a

This eBook curates some of the best thinking from Kinvey and outside experts on how developers should approach Infrastructure as a Service (IaaS). The eBook emphasizes Amazon Web Services (AWS) because its the best known vendor in the space, though we dont recommend one provider over another. The eBook highlights the benets of IaaS, helps in the IaaS vendor selection process, shares best practices for hosting an app on AWS, and provides tips for what to do in case of a service outage.

foundation for Platform as a Service (PaaS) and Software as a Service (SaaS) providers by providing a exible operating environment. In the IaaS environment, the service provider owns, runs and maintains the infrastructure equipment, while the consumer takes responsibility for conguration and operations of the guest operating system, software and database.

A variety of technologies can benet from IaaS: cloud-based CRM systems, web, media and mobile applications, big data systems, and much more. But, IaaS

What is Infrastructure as a Service?

There are a handful of __ as a service (*aaS) providers comprising the mobile and cloud computing ecosystems today. Although individually each company may be unique, collectively they share a common goal: accelerating the rate of innovation by removing costs and barriers to technology deployment. IaaS

is not right for everyone. There are some important factors to consider before determining if your application would benet from IaaS.

Chapte 2 How to Determine if IaaS is right for you


Choosing an IaaS provider is a big decision. You want to trust the provider with your data and, essentially, your entire application infrastructure. As with any service, there are pros and cons associated with IaaS that must be assessed before deciding whether or not to use it for your application.

IaaS may not be right for you if...

usage is minimal or at, and you have no plans to drive signicant growth. Maybe your product is built specically for only a small subset of users (e.g., an internal application for a small company).

You could benet from IaaS if...

there is the potential for spikes in users or usage. Do you have upcoming press coverage that may cause spikes in downloads? Is your application seasonal?

There are pros and cons

associated with IaaS that must be assessed...

you plan to expand your feature set. With an increase in features comes an increased demand on infrastructure. Scalability doesnt only apply to the number of users, sometimes features too need to scale. you dont have a clear sense of your applications storage and networking needs. Successful IaaS deployments benet from clear user up-front requirements. you are an enterprise concerned about youre an individual developer, small dev shop or startup with no existing data center infrastructure or youre an established company taking on a large project that would require signicant additional data center infrastructure or sta. rogue users. (One risk of IaaS is rogue or unwarranted commandeering of services. Because IaaS requires governance and usage monitoring, Vordel's Mark O'Neill recommends that enterprises establish cloud service governance frameworks that help prevent employees from accessing you have a low server-to-admin ratio and are looking to cut costs. information or services they are not permitted to use.)


types, and supported operating

The Major IaaS Players: A Comparison

Once youve decided to use an IaaS solution, its time to pick a vendor. While AWS may be the most prevalent player in the space - it is estimated to own roughly 70 percent of the IaaS market there are several other reputable vendors to consider, and many factors to evaluate. Rest assured, there are plenty of resources out there to help you narrow down the options.


Another way to size-up vendors is by common user concerns, which is the thrust of this second TechRepublic chart. Specically, the table assesses vendors against security features (certications and protection), ease of migration (open standards and VM upload), and reliability [service age, Service Level Agreement (SLA), and support].

This chart from TechRepublic evaluates the best-known IaaS providers against how they compare to common cloud promises. The comparison takes into account a range of factors, including pricing (variety, average, data transfer

Beyond data, developers

want to tap into many tools and services that other clever minds have created...

Pro Tips for IaaS Evaluation

Regardless of whether you select an IaaS vendor based on its cloud promises or user concerns, Kinveys lead architect, Shubhang Mani, advises you consider the following:

Is IaaS really the solution you need? Depending on the complexity of your infrastructure needs, you might be better o opting for a higher layer in the stack such as a Platform as a Service (PaaS), or even Backend as a Service 5

and storage costs), scalability (scaling up and down, monitoring, and APIs), and choice / exibility (number of data center locations, number of instance


(BaaS). The advantages of choosing these alternatives are reduced operational complexity and decreased time to market. The disadvantages are reduced control and a narrower set of choices as to the underlying infrastructure components. PaaS or BaaS might be a good starting point, allowing you to focus on building the application / system until you deem it necessary to exert greater control on the choice of infrastructure components.

Plan for the worst case No system is infallible. Outages can occur, even at your cloud provider of choice. It is important that you have a plan in place to address this were it to occur. For example, you should consider osite backups for your critical data and alternate deployments from your main location.

Understand your support requirements Not all IaaS providers provide the same levels of support. In some cases, support

IaaS is not a silver bullet Some key benets of IaaS include ease in deployment, redundancy, and the ability to scale much faster than conventional means. Deploying a distributed system, especially across geographic regions, can also be achieved in more easily.

is priced independently from the actual product and may end up being quite expensive. Most providers oer a free support level via community forums. This may or may not be sucient depending on your needs.

With so many factors to consider, However, it is important to note that while IaaS gives you the means to provision, deploy and scale infrastructure, it is up to you to congure, monitor and maintain said infrastructure and use it in a manner that makes the most sense to your system. You might be able to build multiple redundancies into a complex system sitting across geographic regions in a matter of hours, but if your rewall rules are improperly congured, youre still vulnerable to attack. selecting an IaaS vendor for your app is arguably the most dicult part of the process. The next step is actually deploying your app on the chosen IaaS provider. Because AWS is the most popular vendor it will be the main focus moving forward.

5 best practices for deploying an application on AWS

Amazon Web Services is a major Infrastructure as a Service provider that provides elastic capacity, quick deployment and automation for applications 6


without using capital expenditure. Within AWS are several infrastructure building blocks, including EC2, S3, and RDS, to name a few. Click here for a full list of AWS products for mobile application hosting.

Familiarize yourself with these tools before diving in.

Start small
Start by moving a small project to AWS before your full project is underway. This way you can fully test and learn

AWS may be a compelling choice for your apps infrastructure needs, but remember, if you want more than just hosting, there are other categories of *aaS vendors, such as Platform as a Service, Software as a Service, and Backend as a Service, that address dierent application needs. You may want to consider vendors in adjacent service categories as well. That said, below is a list of best practices for hosting an app on AWS.

about the various components that youll be using without worrying about managing an entire project.

Start free. Consider starting with Amazons free tier to test and become familiar with the

Use the right tool for the job.

Alex Handy, Senior editor of SD Times, advises: Know what your project/application is and the problem it solves before you dig in. Let AWS manage the infrastructure so you can focus on the business you do best. As previously mentioned, there are several services within the AWS oering. Alex suggests combining multiple: For example, try Amazon Relational Database Service for your database, AWS Elastic Beanstalk for your development environment, or Amazon Elastic Map Reduce for your Hadoop cluster and Big Data needs. 7

Know what your project/appliccation is and the problem it solves before you dig in.

platform before jumping into a full development eort. You get 5GB of storage free for a year on S3, so you can easily back something up for free to see if AWS is the way to go.

Leverage multiple availability zones.

If you want your app to be fault-tolerant, mirroring across availability zones is key


for high availability and disaster recovery. Ensure your design anticipates and manages component failure to signicantly reduce the chances of it failing.

unforeseen outages due to factors out of our control. If it wasnt AWS, it would be the other cloud provider you chose. But there is still hope: when AWS is down, you can still be up if you take the proper measures to prepare for possible outages in advance.

4 things you didnt know about AWS

...always have a backup

plan in the event of an outage

outages The eastern region of the US is the most likely area to suer outages because ...
it has the oldest data centers. it is the largest in terms of data center footprint. it is the default region for most customers, who dont bother changing it

Design for failure and nothing will fail

Understand Amazons disaster recovery principles, and always have a backup plan in the event of an outage. Our developers have compiled multiple guides on recovering from and preparing for an Amazon outage - take a look at the next segment, and learn how to be proactive for the sake of your application.

because its cheaper and/or they arent aware they can change the region.

Availability zones are guaranteed to be distinct per customer only.

However, there are no guarantees as to the composition of the availability zone across customers. To illustrate, if you launch an instance in availability zone 1a and a dierent customer launches an instance in their availability zone 1a, the two instances are not guaranteed to run on the same subset of physical infrastructure. This is why Amazon does not specify or call out names of availability zones in their outage status updates, because 1a for one person could be 1d for another. 8

AWS outage survival guide

An outage on your cloud service provider likely means an outage for your app and thus a delay in the experience on the user-end. This can be extremely detrimental to your apps ratings and overall usage. The unfortunate truth is that everyone has


Some outages are worse than others.

This is because outages that aect core infrastructure components such as Amazon EBS (Elastic Block Store) have a ripple eect on other AWS products that utilize these components. For example, it is possible to provision an EC2 instance using ephemeral storage that is bound to the instance. This instance does not utilize EBS and should theoretically be impacted to a lesser degree. Lets say you have an application that runs on this instance. This application also uses a MySQL database and youve opted to use Amazons Relational Database Service (RDS). Now youre back to (potentially) being aected by an EBS outage since RDS uses EBS for storage. This means that theres a fairly large spike in trac hitting the control plane which invariably results in slowdowns and timeouts. Another side eect of the outage could also be to render the control planes unusable, especially if the outage aects components that are used to service the control planes themselves. This results in customers being unable to minimize downtime faced by their application / systems. A potential solution to this would be to have a hot / cold standby set of components ready in a dierent region. When the outage occurs, it would be a matter of bringing these components online with the understanding that outages that span regions are far less likely than

Amazon provides a rich set of APIs that allow users to access the control plane for various infrastructure components.
In fact, a judicious use of these APIs via client libraries and scripts is what allows one to be able to do things like launch new instances based on trac volume and / or provision new infrastructure as necessary. When an outage occurs, aected customers attempt to remediate their situation by trying to provision new servers in other availability zones and / or regions in order to redirect web trac and/or proceed with other tasks. 9

those within a single region.

Chapte 3 Surviving AWS Failures with a node.js & mongoDB Stack





In this segment, well explain how to fully prepare for an AWS EC2 outage with a node.js and MongoDB stack. Node+Mongo on EC2 is a very popular software stack among web services developers. There are many user guides on how to design this system with built-in redundancy so that even coordinated failures dont bring down the service. The absolute minimum for a resilient service requires a MongoDB replica set behind a load-balanced node farm.

MongoDB instances should each be load balanced across multiple Availability Zones. The more the better.

4. Place the node servers and the mongo servers all in a security group, which allows only the Mongo ports internally and your application ports externally. This is trivial to set up and protects your database from external requests.

5. MongoDBs authentication provides additional protection. Mongos security

You are not ready for an EC2 outage until you have deliberately shut down components in your system and veried the expected behavior. As you periodically do this, you might discover that there are gaps you did not account for. Take the following steps to be as prepared as possible:

model has limited robustness, but having authentication in your MongoDB store is still useful even if the application and the database are inside an EC2 security group. For your data to get exposed, you will have to make multiple mistakes at the same time, which happens, but the chances are greatly reduced.

1. A Node.js single event will by default crash on an unhandled exception. Use upstart or forever to restart the process. 6. Ensure that failover happens smoothly. Shutdown the primary Mongo instance and see what happens as requests keep 2. Use Monit, an external process on your server that makes liveness checks and potentially restarts your service. Monit will also email you if and when it had to restart. While upstart ensures that your process is up, monit ensures that it is responsive. 7. What this error message means is that the failover happened, but your 3. Your application instances and your 11 applications request is not authenticatcoming in. The replicas notice the down primary and one of them takes over, but upon an incoming request you see this error message: unauthorized db:mydb lock type:-1 client:


ed. This is an example of an esoteric bug that may not show up until you do a full end to end test. The bug is now in a pull request. Since pull requests dont get released quickly, use npm git dependencies to install your app from your forked repo.

GoDaddy, unfortunately this guide cannot help - youll just have to wait until GoDaddy is back online. 1. To start, log into the Route 53 dashboard in the AWS Console.

8. While you have a down MongoDB instance, it may take a long time for your application to restart. The default in node-mongodb-native is no timeout, which means leaving it down to the OS. To avoid yet another timeout cycle, use Mongos connectTimeoutMS setting.

...know how your application fails when a network service like DNS is unavailable

9. This ensures that your restarts will take a little over 500ms, if you have a down instance. However, dont assume that your Mongo SDK supports it node-mongodb-native doesnt, unless you use this github patch.

2. As the landing page describes, your rst step is to create a hosted zone. A hosted zone is a concept created by Amazon to describe a collection of DNS records (i.e. A records, CNAME records, MX records) that are managed together under a single parent domain name. You

10. You are now prepared for an AWS outage. Bring it on.

can use the Route 53 dashboard to manage these hosted zones. For a good explanation of the dierent types of DNS records, check out Googles guide.

Migrating from GoDaddy DNS to Amazon Route 53

This next guide walks through the process of migrating from GoDaddy hosting to Amazons Route 53. This only applies to domain names that are controlled by another registrar, where GoDaddy is used just for hosting. If the domain name itself is controlled through 12

3. Click Create Hosted Zone, and ll in your domain name in the form that appears on the right.

4. When you created the hosted zone for your domain, Route 53 lled in some basic DNS records. To see them, select

DEVELOPERS GUIDE TO AMAZON WEB SERVICES your domain name from the list, and click Go to Record Sets in the top right. Youll see that Route 53 populated your domain with a set of NS records and SOA records. with your application. If your app relies on DNS to connect to another server (i.e. database), it may stop trying after a few failed lookups. At this point things probably require manual intervention, even if the DNS service recovers. The key 5. Your current site may have extra DNS records needed. For example, if you host a blog on Tumblr, you probably have a CNAME record setup to create that link. Also, if you receive email at your domain, you probably have an MX record set for that. Make a list of all these extra records youll need, and add them now (use the Create Record Set button). To prevent manual intervention, you can use a tool called Monit. Monit is a daemon that is responsible for monitor6. Finally, its time to make the switch. Head over to your current registar, and change the nameservers from the GoDaddy addresses to the ones provided in the NS record set on your Route 53 dashboard. Note: because DNS servers around the world cache this value, it may take some time to see the change work while the update propagates through the DNS system. Lets take a look at a basic cong to start: ing your server and application health. It can also be congured to check the health of external services such as DNS. takeaway from this is that you should know how your application fails when a network service like DNS is unavailable. And you should know whether or not it will require manual intervention to recover.

This cong monitors an HTTP application

Recovering from a DNS service outage in AWS using Monit

Our nal AWS outage survival guide uses a tool called Monit to recover from a DNS service outage. A DNS failure isnt something you see everyday at AWS, but when it happens it can cause problems

that listens on on port 9009. When there is a failure, Monit alerts you and attempts to restart the process. We dont want to constantly restart the service if it is unhealthy, so if the app fails 10 times within 10 cycles, then Monit will leave the app o and stop 13


monitoring it.

re-enables monitoring. It also disables our aws-dns-healthcheck since we know

When a network service fails like DNS, your application becomes unhealthy, tries to restart 10 times, and then becomes unmonitored. Now youre at a point where things require manual intervention to recover, even if DNS becomes available. Lets congure Monit to take care of everything for us.

DNS is healthy.

You should now be able to recover your app during a DNS failure. To be 100% sure this works as intended, we can simulate another DNS outage using iptables.

Run this command: sudo iptables -A Building on our previous conguration: OUTPUT -p udp dport 53 -j DROP This command will prevent any DNS queries from completing. If your app relies on DNS you should see it fail once its DNS cache has expired. This should trigger the DNS check to be enabled via Monit. You can check the status of Monit - Were still monitoring our HTTP app on port 9009 - When the application fails now, it kicks o the aws-dns-healthcheck monitor. - The aws-dns-healthcheck monitor checks to see if it can resolve DNS on (the default AWS DNS server). - When DNS reports healthy for 3 cycles, monit execs a script to try to recover the app. Your application should now try to recover after the DNS check returns to a healthy state. The examples above focus on how to approach a failure in the DNS service. In reality there could be a myriad of The example recovery script is simple: external services that may aect the health of your app. You can use the same approach as described above and It calls /usr/bin/monit start appsrv1 which will attempt to start the app and 14 expand the aws-dns-healthcheck into a generic health check for your applicaTo re-enable DNS run this: sudo iptables -F monitoring using the command: sudo monit status


tion. This could include testing network connectivity, connectivity to external services (e.g: a database), and any other processes that your app depends on. You can nd examples for monitoring all kinds of services on the Monit website here.

Again, the takeaway from this is to know how your application behaves under dierent failure scenarios. Testing connectivity loss, loss of network services, and other failures are very important when building a high availability application.


Written by
Kelly Rice and Shubhang Mani

Designed by
Jake McKibben

Survival Guide Authors

Ivan Stoyanov, Dave Wasmer and Joey Imbasciano

Written by
Kelly Rice and Shubhang Mani

Designed by
Jake McKibben

Survival Guide Authors

Ivan Stoyanov, Dave Wasmer and Joey Imbasciano