Architecting for the Cloud, Part 3: Working with Amazon Cloud

So, you’ve decided to utilize Amazon’s Web Services. While we’ve discussed cloud architecture in several previous blogs, Amazon’s cloud services come with their own possibilities and challenges. The scalability and elasticity of AWS is powerful, but you’ll have to fully adapt to the AWS mindset to reap the benefits of the system without ratcheting up the cost. Here are some key factors you want to keep in mind as you dive into the AWS system.

Use only what you need.

First of all, Amazon offers three different models for cloud-usage. These are Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS). This stable of models is intended to provide flexibility, so your focus should be only taking on the services you actually need, rather than paying for an all-in-one system with components that go unused even though you’re funding them.

Focus on AWS’s flexibility.

This focus on paying for what you actually need and use pervades Amazon’s cloud service. Amazon’s pricing structure is per use, and AWS allow you to scale up and down on the fly. Fight the temptation to choose a more robust base scale than you’re actually using. It misses the point of Amazon’s cloud model, which allows you to auto-scale, and also to manually scale up in minutes if necessary.

This means that AWS is an ideal partner in a DevOps model. Its fluidity and scalability ensure that your cloud service can keep up with the back and forth that’s so vital to the DevOps process. When you’re rolling out code 30 times more frequently than a traditional development team, that’s important!

Plug resource drains.

In addition to overestimating need, the main issue users run into when working with Amazon cloud architecture is cost overage based on inattention. Organizations scale up based on short-term need, and forget to scale back down or turn off instances afterwards. It’s equally important to balance the flexibility of the system with your actual storage needs. As one example, AWS allow you to take “snapshots” of EBS, or Elastic Block Storage volumes. This can be incredibly beneficial if you need to roll back to an earlier version. However, if you get “snap happy”, you’re going to end up storing myriad versions of each EBS, and you’ll keep paying for them long after they’re defunct. Regular AWS system clean-ups need to be scheduled into your workflow when you’re working with AWS.

Leverage the AWS ecosystem.

In addition to keeping your AWS system lean, make sure you exploit the resources available to you. For one thing, consider spreading out your workload to prevent and minimize outages. Amazon uses multiple “availability zones”, and there’s no reason to allocate your entire workload to one data center!

There are a cluster of related services provided by Amazon to maximize AWS’s effectiveness. You can put the AWS Gateway to work and implement an on-site application coupled with cloud storage. You also have the power of Lambda, which allows you to run data or file processing codes without having to worry about managing a server. Lambda can be useful for smaller tasks like re-scaling images for mobile apps or fielding IoT requests. You only pay per 100ms of runtime. And the Cognito service provides that handy little button that lets your users authenticate themselves through another app they already use, such as Facebook.

Don’t Go It Alone

At first glance, it might seem like AWS does everything you need it to on your own. But remember that it’s only a tool. A complicated tool, sure, but still a tool, and any tool is only as useful as the skill of the people wielding it.

This is why it’s so crucial that you find a good partner when building your AWS system. Cloud systems are crucial pieces of company operations, and it’s absolutely vital that they’re built correctly. Even if you have a good understanding of AWS, bringing in another set of experienced hands is the best way to make sure that your setup is as robust as possible.