Successfully reported this slideshow.

Growing Up with AWS

0

Share

Loading in …3
×
1 of 20
1 of 20

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Growing Up with AWS

  1. 1. Growing Up with AWS 5 ways to ease the pain
  2. 2. Paul Wakeford @paulwakeford www.paulwakeford.info github.com/paulwakeford au.linkedin.com/in/paulwakeford
  3. 3. ◦ About 30 AWS accounts ◦ ~800 instances ◦ Still migrating services ◦ Seven digit yearly AWS bill
  4. 4. Tag everything1
  5. 5. Name consistently2
  6. 6. Account segregation3
  7. 7. Cost control4
  8. 8. Cost saving tools ● AWS tools - Trusted Advisor, Cost Analysis and Reports, standard & scheduled RIs, Autoscale scheduling, billing alerts ● Open source - such as CloudCycler/FlyWheel - http://j.mp/awscost ● Third party tools - Cloudability, CloudCheckr, ParkMyCloud etc
  9. 9. CloudCycler impact
  10. 10. Automate everything5
  11. 11. Automating AWS resource creation and management ● Use an AWS infrastructure automation creation tool - Cloudformation, Terraform, Rightscale.. ● Use a configuration management tool - Puppet, Chef, Ansible, Salt.. ● Use open source tools or write your own - manage snapshots & backups, manage tags, security alerting etc
  12. 12. Goal Do It Once!
  13. 13. Questions?? @paulwakeford www.paulwakeford.info github.com/paulwakeford au.linkedin.com/in/paulwakeford
  14. 14. CREDITS Special thanks to all the people who made and released these awesome resources for free: ◦ Presentation template by SlidesCarnival ◦ Photographs by Unsplash

Editor's Notes

  • About me. I have about 20 years of IT experience, architect there since 2007. Using AWS since 2012 (Singapore days). I work for Fairfax Media, in the online side of things, so primarily on these properties...
  • But not Domain, they do their own thing.
  • To show our rate of growth, this is a graph of our daily EC2 instance hours, from May 2013 to December 2015. Growth is about 7x.

    I hope there’s something for everyone in this presentation - if you are a smaller player you can learn what to do before you get big, and if you are already big, it’s not too late to change.
  • Tags are labels - a key/value pair you can apply to most AWS resources - EC2 instances, EBS volumes, S2 buckets etc. Use tags everywhere. You can have up to ten tags. Tags are case sensitive. We use Project to identify resources for cross charging, Expires is used by a snapshot tool. Come up with your own tags based on your use cases - the important thing is to have a standard and stick to it. You may need a Tag Policeman. Yes not everything can be tagged.
  • Tag support in the console is much better now - you can edit tags, find resources that are not tagged correctly, and create groups of tagged resources. And of course the CLI fully supports tagging. There are third party tools to manage tagging too - I’ve contributed to Graffiti Monkey, a tag inheritance tool for EBS volumes and snapshots, which is on Github.
  • If you get three engineers in a room to discuss naming object you will end up with at least five naming schemes. I’m not going to say what you should use, but that you should come up with one and stick to it. For example this is our server/instance naming scheme. [Describe]
    Some say that tagging means naming is less important - this is a little true, but naming still has a place. e.g. names can be imported into CMDBs, or can indicate other information - for example these IAM users are service accounts (noted by them starting with ‘svc-’) so use API keys only - one having a password would be a red flag for further investigation.
  • Think about when you should split off into separate accounts. Sure, you can split off into VPCs but there are two main reasons why you might want to have multiple accounts - cost and security.
    Cost - even with tagging you can’t 100% allocate costs to a business unit or a project or a client. An AWS account is a cost boundary.
    Security - do you want BUs to be able to terminate everyone’s instances? Or start up instances and run up big bills? Sure you can write policies to restrict these actions but do you want to spend that time and restrict creativity? Easier to put project X in a separate AWS account where they can do what they like and be responsible for billing too.
    This is the biggest issue we face now at Fairfax.
  • Use consolidated billing with multiple accounts - one bill, and volume usage discounts.
  • Talking of costs...
  • Cost section of TA requires a support plan
    Cost reporting has improved a lot - if you haven’t used it recently take a look.
    Open source tools - Fairfax have written a couple, CloudCycler and Flywheel, [describe].
    Check the link for usage.
    Third party tools
  • Impact of CloudCycler showing half way through.
  • An example from CloudCheckr.
  • We use Cloudformation to build everything, from single server solutions to multiple VPC ones. Templates are under source control, tagging built in.
    We use Puppet as it’s what we used in the on prem days.
    We have our own snapshot management tools, bucket backup scripts, etc.
    We use CloudCheckr for automated security reporting (open SGs etc), Security Monkey is an alternative, I’m unsure how well maintained it is now.
  • Your goal is for whatever you do, do it once then replicate it over and over.
  • ×