{"id":1534,"date":"2016-02-25T14:40:17","date_gmt":"2016-02-25T14:40:17","guid":{"rendered":"http:\/\/www.tekhead.org\/blog\/?p=1534"},"modified":"2016-10-09T16:40:40","modified_gmt":"2016-10-09T15:40:40","slug":"amazon-aws-tips-and-gotchas-part-1","status":"publish","type":"post","link":"https:\/\/tekhead.it\/blog\/2016\/02\/amazon-aws-tips-and-gotchas-part-1\/","title":{"rendered":"Amazon AWS Tips and Gotchas – Part 1 – AWS Intro, EBS and EC2"},"content":{"rendered":"

Although I have been very much aware of AWS for many years and understood it at a high level, I have never had the time to get deep down and dirty with the AWS platform\u2026 that is until now!<\/span><\/p>\n

I have spent the past three weeks immersing myself in AWS via the most excellent ACloud.Guru Solution Architect Associate training course<\/a>, followed by a one week intensive AWS instructor-led class from QA on AWS SA Associate and Professional<\/a>.<\/span><\/p>\n

While the 100 hours or so I have spent labbing and interacting with AWS is certainly not 10,000<\/a>, it has given me some valuable insights on both how absolutely AWS<\/i>ome (sorry – had to be done!) the platform is, as well as experiencing a few eye openers which I felt were worth sharing.<\/span><\/p>\n

It would be very easy for me to extoll the virtues of AWS, but I don’t think there would be much benefit to that. Everyone knows it is a great platform (but maybe I’ll do it later anyway)! In the meantime, I thought it would be worthwhile taking a bit more of a “warts and all” view of a few features. Hopefully, this will avoid others stepping into the potential traps which have\u00a0come up directly or indirectly through\u00a0my recent training materials, as well as being a memory aid to\u00a0myself!<\/span><\/p>\n

\"pretty<\/p>\n

The key thing is with all of these “gotchas”, they are not irreparable, and can generally be worked around by tweaking your infrastructure design. In addition,\u00a0with the rate that AWS develop and update features on their platforms, it is likely that many of them will improve over the coming months \/ years anyway.<\/span><\/p>\n

The general feeling around many of these “features” is that AWS are indirectly and gently encouraging you to avoid building your solutions on EC2 and other IaaS services, Instead, pushing you more towards using their more managed services such as RDS, Lambda, Elastic Beanstalk etc.<\/p>\n

This did originally start off as a single “Top 10” post but realised quickly that there are a lot more than 10 items and some of them are pretty deep dive! As such, I have split the content into easily consumable chunks, with a few lightweight ones to get us started… keep your eyes open for a few whoppers later in the series!
\n<\/span><\/p>\n

The full list of posts will be available here:
\n<\/span>Index of AWS Tips and Gotchas<\/a><\/span><\/p>\n

AWS Tips and Gotchas – Part 1<\/b><\/span><\/h5>\n
    \n
  1. Storage for any single instance\u00a0may not exceed 20,000 IOPS and 320MB\/sec per EBS volume.<\/em> This is really only something which will impact very significant workloads. The current “recommended” workaround for this is to do some pretty scary things such as in-guest RAID \/ striping!
    \n<\/span><\/span><\/span>
    \nDoing this with RAID0 means you then immediately risk loss of the entire datastore if a single EBS volume in the set goes offline for even a few seconds. Alternatively, you can buy twice as much storage and waste compute resources doing RAID calculations. In addition, you then have to do some really kludgy things to get consistent snapshots from your volume, such as taking your service offline.\u00a0<\/span><\/span>In reality, only the most extreme workloads hit this kind of scale up. The real answer (which is probably better in the long term) is to refactor your application or database for scale-out, a far more cloudy design.
    \n\"amazon<\/li>\n
  2. The internet gateway service does not provide a native method for capping of outbound bandwidth.<\/em> It doesn’t take a genius to work out that when outbound bandwidth is chargeable, you could walk away with a pretty significant bandwidth bill should something decide to attack your platform with a high volume of traffic.\u00a0<\/span><\/span><\/span>One potential method to work around this would be to use NAT instances. You can then control the bandwidth using 3rd party software in the NAT instance OS.<\/li>\n
  3. There is no SLA for EC2 instances unless you run them across multiple Availability Zones<\/a><\/em>. Of course with typical RTTs of a few milliseconds at most, there is very little reason not to stretch your solutions across multiple AZs. The only time you might keep in one AZ is if you have highly latency sensitive applications, or potentially the type of app which requires a serialised string of DB queries to generate a response to the end user.
    \n<\/span><\/span><\/span>
    \nIn a way I actually quite like this SLA requirement as it pushes customers who might otherwise have accepted the risk of a single DC, into designing something more robust and accepting the (often minor) additional costs.\u00a0With the use of Auto Scaling and Elastic Load Balancing there is often no reason you can’t have a very highly available application split across two or more AZs, whilst using roughly the same number of servers as a\u00a0single site solution.
    \n<\/span><\/span><\/span>
    \nFor example the following solution would be resilient to a single AZ failure, whilst using\u00a0no more infrastructure than a typical resilient on-premises single site solution:\"Teahead
    \nNo DR replication required, no crazy metro clustering setup, nothing; just a cost effective, scalable, highly resilient and simple setup capable of withstanding the loss of an entire data centre (though not a region, obviously).<\/span><\/li>\n<\/ol>\n

    Find\u00a0more posts in this series here:
    \n    Index of AWS Tips and Gotchas<\/a><\/p>\n

    Amazon AWS Tips and Gotchas – Part 2 – AWS EBS & RDS MS SQL<\/a><\/p><\/blockquote>\n