Being Well-Architected in the Cloud
•Download as PPTX, PDF•
7 likes•1,469 views
In this session, you'll learn how to architect your applications based on Amazon Web Services' Well-Architected Framework principles and Adrian’s 10+ years of experience using AWS.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Being Well-Architected in the Cloud
Similar to Being Well-Architected in the Cloud (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Being Well-Architected in the Cloud
- 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Adrian Hornsby, Technical Evangelist @ AWS Twitter: @adhorn Email: adhorn@amazon.com Being Well-Architected in the Cloud
- 2. • Technical Evangelist, Developer Advocate, … Software Engineer • Own bed in Finland • Previously: • Solutions Architect @AWS • Lead Cloud Architect @Dreambroker • Director of Engineering, Software Engineer, DevOps, Manager, ... @Hdm • Researcher @Nokia Research Center • and a bunch of other stuff. • Climber, like Ginger shots.
- 3. What to expect from the session 1. What is the Well-Architected framework 2. Framework Overview 3. How to be Well-Architected 4. Conclusion
- 4. What is the Well-Architected Framework?
- 5. Customer Challenges Faster response to change in market Delivery time Change Management Reduce human errors Faster recovery High availability AutomationScaling to demand
- 8. AWS well-architected framework Security Reliability Performance efficiency Cost optimization Set of questions you can use to evaluate how well an architecture is aligned to AWS best practices Operational excellence
- 10. AWS Global Infrastructure 16 Regions 42 Availability Zones
- 11. Building Blocks EC2 instance Server Subnet Availability Zone A Availability Zone B Region Amazon S3 Amazon CloudWatch Availability Zone C
- 12. Security pillar
- 13. Security pillar Security at all layers Enable traceability Implement a principle of least privilege Focus on securing system Automate security best practices Protect information, systems, and assets while delivering business value through risk assessments and mitigation strategies
- 14. Shared Responsibility AWS Foundation Services Compute Storage Database Networking AWS Global Infrastructure Regions Availability Zones Edge Locations Client-side Data Encryption Server-side Data Encryption Network Traffic Protection Platform, Applications, Identity & Access Management Operating System, Network, and Firewall Configuration Customer applications & content Customers
- 15. Credentials • Enforce MFA for everyone from day 1. • Use AWS IAM Users and Roles from day 1. • Enforce strong passwords. • Protect and rotate credentials. • No access keys in code.
- 16. EC2 Role 1: Create EC2 role Create role in IAM service with limited policy 2: Launch EC2 instance Launch instance with role 3: App retrieves credentials Using AWS SDK application retrieves temporary credentials 4: App accesses AWS resource(s) Using AWS SDK application uses credentials to access resource(s) Instance
- 17. IAM Policies { "Version": "2012-10-17", "Statement": [ { "Sid": "AddPerm", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*" } ] }
- 18. Network and Boundary • Security groups are built-in stateful firewalls • Divide layers of the stack into subnets • Use a bastion host for access • Implement host based controls
- 19. Layers with Security Groups Availability Zone A User WEB Server RDS DB Instance Web Subnet A DB Subnet A WEB Security Group DB Security Group
- 20. Bastion Host & Security Groups Availability Zone A Developer WEB Server RDS DB Instance Public Subnet A Private Subnet A WEB Security Group DB Security Group Bastion Host Bastion Security Group Port 22 IP restriction > start_bastion > ssh -A > stop_bastion
- 21. Monitoring and Auditing • Capture & audit AWS CloudTrail, Amazon VPC and Amazon CloudWatch logs. • Collect all logs centrally. • Setup alerts. Amazon Virtual Private Cloud AWS Identity & Access Manager AWS Key Management Service AWS CloudTrail AWS Config
- 24. Audit logs for all operations Store/Archive Troubleshoot Monitor & Alarm
- 25. Verify everything, always, with AWS Config
- 27. Reliability pillar Test recovery procedures Automatically recover from failure Scale horizontally to increase availability Stop guessing capacity Ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues
- 28. High Availability • No Single Point of Failure • Multiple Availability Zones • Load Balancing • Auto Scaling and Healing
- 29. Web Instance RDS DB Instance Active (Multi-AZ) Availability Zone Availability Zone Web Instance RDS DB Instance Standby (Multi-AZ) Load balancer Multi-AZ Architecture Available & redundant application User Amazon Route 53 Amazon CloudFront Amazon S3
- 30. Sunday Monday Tuesday Wednesday Thursday Friday Saturday Weekly traffic pattern
- 31. Auto Scaling • Maintain your Amazon EC2 instance availability • Automatically Scale Up and Down your EC2 Fleet • Scale based on CPU, Memory or Custom metrics
- 32. RDS DB Instance Active (Multi-AZ) Availability Zone Availability Zone RDS DB Instance Standby (Multi-AZ) ELB Auto scaling groups User Amazon Route 53 Amazon CloudFront Amazon S3 Web Instances Web Instances ElastiCache Auto-Scaling group
- 33. Backup and DR • Define Objectives • Backup Strategy • Periodic Recovery Testing • Automated Recovery • Periodic Reviews
- 35. Performance efficiency pillar Democratize advanced technologies Go global in minutes Use the right architectures for your backend and databases Experiment more often Efficiently use of computing resources to meet requirements, and maintaining that efficiency as demand changes and technologies evolve
- 36. Right Sizing • Reference Architecture • Quick Start Reference Deployments • Benchmarking • Load Testing • Cost / Budget • Monitoring and Notification
- 37. Utilization vs Provisioned capacity 76% 24% November
- 38. Proximity and Caching • Content Delivery Network (CDN) • Database Caching • Reduce Latency • Pro-active Monitoring and Notification Amazon CloudFront Amazon ElastiCache RDS DB instance read replica
- 39. • Cache content at the edge for faster delivery • Lower load on origin • Dynamic and static content • Streaming video • Custom SSL certificates • Low TTLs Amazon CloudFront (CDN)
- 41. Message passing A Queue B A Queue BListener Pub-Sub SNS, SQS, Redis, RabbitMQ
- 42. Async. Architecture (part 1) Web Instances Worker Instance Worker Instance Queue API Instance API Instance API Instance API: {DO foo} PUT JOB: {JobID: 0001, Task: DO foo} API: {JobID: 0001} GET JOB: {JobID: 0001, Task: DO foo} ElastiCache Result: { JobID: 0001, Result: bar }
- 43. Async. Architecture (part 2) Worker Instance Worker Instance Queue API Instance API Instance API Instance ElastiCache Amazon SNS Push Notification User
- 44. RDS DB Instance Active (Multi-AZ) Availability Zone Elastic Load Balancer Web Instance Web Instance Amazon Route 53User Amazon S3 Amazon Cloudfront ElastiCache Worker Instance Worker Instance Full Decoupling Queue Amazon SNS
- 46. Event driven A B CEvent on B by A triggers C
- 47. How Lambda works S3 event notifications DynamoDB Streams Kinesis events Cognito events SNS events Custom events CloudTrail events LambdaDynamoDB Kinesis S3 Any custom Invoked in response to events - Changes in data - Changes in state Redshift SNS Access any service, including your own Such as… Lambda functions CloudWatch events
- 48. Event-driven using Lambda AWS Lambda: Resize Images Users upload photos S3: Source Bucket S3: Destination Bucket Triggered on PUTs
- 49. Databases
- 50. Read / Write Sharding RDS DB Instance Read Replica App Instance App Instance App Instance RDS DB Instance Master (Multi-AZ) RDS DB Instance Read Replica RDS DB Instance Read Replica
- 52. Database Sharding User ShardID 002345 A 002346 B 002347 C 002348 B 002349 A CBA App Instance App Instance App Instance
- 54. Database specialization example: Redis In-memory data structure store, used as a database, cache and message broker. Specialized in data structures such as • string • hashes • lists • sets • sorted sets with range queries • bitmaps • hyperloglogs • geospatial indexes with radius queries
- 55. Cost optimization pillar Analyze and attribute expenditure Managed services to reduce TCO Adopt a consumption model Benefits from economies of scale Stop spending money on data center operations Assess your ability to avoid or eliminate unneeded costs or suboptimal resources, and use those savings on differentiated benefits for your business
- 56. Pricing Model • On Demand • Reserved • Spot • Dedicated
- 57. Auto Start/Shutdown of Instances AWS Lambda Amazon Cloudwatch Rules: every day at 21h30 Rules: every day at 6h15 Sleep trigger Wakeup trigger AWS Resources (EC2 instances)
- 58. Managed Services • Let AWS do the heavy lifting. • Databases, caches and big data solutions. • Application Level Services. Amazon RDS Amazon DynamoDB Amazon Redshift Amazon ElastiCache AWS Elastic Beanstalk Amazon Elasticsearch Service
- 59. Manage Expenditure • Tag Resources • Track Project Lifecycle • Profile Applications vs Cost • Monitor Usage & Spend
- 60. Auto Tagging resources as they start Amazon Cloudwatch AWS LambdaEvents: RunInstances EC2 Instances Tag: Owner = userName PrincipalId = aws:userid
- 62. Operational excellence pillar Perform operations with code Align operations processes to business objectives Make regular, small, incremental changes Test for responses to unexpected events Learn from operational events and failures Keep operations procedures current Operational practices and procedures used to manage production workloads
- 63. Infrastructure-as-code workflow code version control code review integrate “It’s all software” • Create templates of your infrastructure. • Version control/replicate/update templates like code. • Integrates with development, CI/CD, management tools AWS CloudFormation
- 64. Some tips … from my own experience • Architecture as code – code everything. • Automate everything: “Invest time to save time” • Don’t reinvent the wheel; managed services are your best friends. • Embrace security early on. • Test your DR strategy regularly. • Serverless architectures free you from managing infrastructure. • Did I mention automation?
- 65. The “Must” from Day 1 • High quality code • Version controlled • CI/CD pipeline • Infrastructure as code • Security at every layer • Cost conscious • Test & Monitor everything • DR procedure Operational Excellence
- 66. And don’t forget …
- 67. Trusted Advisor
Editor's Notes
- dilauro@2016-11-28 – Updated Performance to Performance Efficiency, Added Operational Excellence
- And finally… lots of options for global deployment. Gartner estimates that AWS has significantly more compute capacity than all other major cloud providers combined, and we do that while providing extremely high reliability. We currently provide 16 regions and 42 availability zones (or AZ’s). For us, a region will always contain at least two AZ’s on wholly separate power grids and flood plains, and an AZ is always comprised of multiple data centers to provide redundancy within the AZ. We don’t build single data center regions, because it wouldn’t offer the reliability required for enterprise businesses. This highly available global network allows you deploy your applications near your customers much faster and simpler than what can be achieved with a traditional model.
- I’ll just go over some of the basic building blocks first. Amazon EC2, our compute service, provides you the ability to place a server, what we call an instance, in these locations. They are isolated from each other from failure, are highly connected so you can run true highly available applications across them. We also have services like S3 our object storage service that resides in the region however runs as a service across the whole region
- dilauro@2016-11-28 – Changed Automate response to “Implement a principle of least privilege” and associated image
- The moment you create a new AWS account you need to secure it, as it is your virtual data centre. The identity and access management service provides a very powerful way of governing access to your resources, even if you have one user, setup a user login and do not use what we call the root or your email address to sign in. Besides login credentials you can also generate access keys that are a programmatic way to to gain access to your resources, these access keys should never, ever, be put into code or stored insecurely.
- A security group is a stateful firewall that is a free built in feature to allow only the incoming network traffic that you allow, use them wisely to allow only what is absolutely necessary. Divide your stack into different layers, say the web and database layers into different subnets. this allows for logical isolation and also control over the routing. Bastion or jump boxes are great to restrict administrative access to, and of course you can just turn them off and not pay for them while they are not in use. host based controls such as ip tables and anti-malware should also be implemented.
- Adding to the building blocks I showed you earlier you can see a single web and single database instance with a security group for each and an end user accessing directly
- Adding to the building blocks I showed you earlier you can see a single web and single database instance with a security group for each and an end user accessing directly Using ssh -A for ssh agent forwarding You mustn't put personal ssh private keys on shared systems or servers. It is a pretty serious security risk: if anyone else has access to the system, they have access to your ssh private key, and may be able to use that to impersonate you.
- Going to the instance level now, monitoring and alerting are key and understanding what a normal state looks like in your application. We also have some great services such as CloudTrail that we highly recommend you enable, VPC flow logs which provide visibility of network traffic flow and help in trouble shooting. Finally encryption everywhere is key, for our block storage service EBS and S3 its simply a check box
- High availability is the holy grail of reliability, whether its unexpected downtime or scheduled maintenance your system will continue to run. You can utilise different availability zones for high availability and for a web workload load balance across the zones. AWS has an auto scaling service which based on your parameters can add or reduce compute instances
- Next up we need to address the lack of failover and redundancy in our infrastructure. We’re going to do this by adding in another webapp instance, and enabling the Multi-AZ feature of RDS, which will give us a standby instance in a different AZ from the Primary. We’re also going to replace our EIP with an Elastic Load Balancer to share the load between our two web instances Now we have an app that is a bit more scalable and has some fault tolerance built in as well.
- At the stage, you typically start to have a significant amount of traffic and you can already detect patterns (usage patterns) This is amazon.com usage patterns.. East and weast coast ..
- Backup and disaster recovery is another key aspect of reliability, using automation tools and with infrastructure driven by code allows for scenarios where automatic recovery is possible. You should of course always test your backups and review your strategy. *EBS SNAPSHOTS S3 VERSIONING
- Amazon Redshift is a fast, fully managed, petabyte-scale data warehouse that makes it simple and cost-effective to analyze all your data using your existing business intelligence tools. A cluster is automatically backed up to Amazon S3. Default: three automatic snapshots of the cluster retained for 24 hours. You can restore manual snapshots into new clusters at any time. When creating cluster backups for a production system, you must carefully consider two dimensions: RTO: Recovery Time Objective. How long does it take to recover from disaster recovery scenario? RPO: Recovery Point Objective. When you have recovered, to what point in time will the system be consistent? Recovery Time Objective When using Amazon Redshift, your RTO is determined by the node type you are using, how many of those nodes you have, and the size of the data they store. It is vital that you practice restoration from snapshots created on the cluster to correctly determine Recovery Time Objective. It is also important that you re-test the restore performance any time you resize the cluster or your data volume changes significantly. Recovery Point Objective Automated backups are triggered based on a threshold of blocks changed or after a certain amount of time. For a cluster with minimal changes to data, a backup is taken after approximately every 8 hours. For a cluster which churns a massive amount of data, backups can be taken several times per hour. If you find that your data churn rate isn’t triggering automated backups at a frequency which satisfies your RPO then this utility can be leveraged to supplement the existing automated backups with additional manual snapshots in order to guarantee the targeted RPO. https://github.com/awslabs/amazon-redshift-utils/tree/master/src/SnapshotManager https://aws.amazon.com/blogs/big-data/simplify-management-of-amazon-redshift-snapshots-using-aws-lambda/#more-26 https://github.com/awslabs/amazon-redshift-utils/tree/master/src/SnapshotManager
- dilauro@2016-11-28 - added efficiency to title
- I've shown you Elastic Beanstalk, our reference architectures or even one of the quick start deployments we have available can also be a great way to start especially if you are not familiar with a particular environment. Benchmarking and load testing play an important role in the tuning of your application, know how it behaves under load and also lets you get the auto scaling parameters right
- That’s a lot of potential wasted infrastructure and cost. 76% wasted potentially, while only 24% of it on average for the month gets utilized. Traditionally this is how IT did things. You bought servers for a 6-12 month vision on what growth might be. So, since we can all agree this is bad, what is the solution.
- Proximity and caching are key to reducing the latency between your application and your users, for example a web application you can use cloudfront our global content delivery network service to cache content close to the user at one of our 50+ edge locations. Caching is not just for the web layer you can also implement at the database layer using the ElastiCache service based on memcached or redis, or even just read replicas of your primary database. sometimes read replicas can be the easiest to implement as you just need to direct read requests to a different end point and the improvements can be huge.
- Cloudfront allows you to cache static content at the CF edge for faster delivery from a local pop to the end user; in other words, your static content gets cached locally to a user and then delivered locally reducing download times for the website overall there are over 60 CF cache pops around the world as we mentioned earlier. CloudFront helps lower load on your origin infrastructure You can front end static content as discussed and dynamic content as well For dynamic content, CF proxies and accelerates your connection back to your dynamic origin and you would set a 0 ttl on your dynamic content so CloudFront always goes back to origin to fetch this content.
- Write and updates Counters!!!! Not on the DB – redis!!
- Database Federation is where we break up the database by function. In our example, we have broken out the Forums DB from the User DB from the Products DB Of course, cross functional queries are harder to do and you may need to do your joins at the application layer for these types of queries This will reduce our database footprint for a while and the great thing is, this does prevent you from having to shard until much further down the line. This isn’t going to help for single large tables; for this we will need to shard.
- Sharding is where we break up that single large database into multiple DBs. We might need to do this because of database or table size or potentially for high write IOPs as well. Here is an example of us breaking up a database with a large table into 3 databases. Above we show where each userID is located, but the easiest way to describe how this would work would be to use the example of all users with A-H go into one DB, and I – M go in another, and N – Z go into the third DB. Typically this is done by key space and your application has to be aware of where to read from, update and write to for a particular record. ORM support can help here. This does create operation complexity so if you can federate first, do that. This can be done with SQL or NoSQL, and DynamoDB does this for you under the covers on the backend as your data size increases and the reads / writes per second scale.
- When we start getting into the 5M user plus range, we may start seeing database contention issues on writes to the Master We are going to drill into a couple of techniques to solve these types of issues, and those include Federation and Sharding
- dilauro@2016-11-28 – added ”pillar’ to title, Change ”Trade CapEx for Opex” to “Adopt a consumption model”; changed “Remove overall data center operations cost” to “Stop spending money on data center operations”; changed “Transparently attribute Expenditures” to “Analyze and attribute expenditure”
- Instances can be procured in a few different ways, the default is on demand, reserved instances allow you to commit for 1y or more with varying options to receive a discount if you are running them 24x7. Spot instances allow you to take advantage of the spot market where we auction off unused capacity at discounted prices, however their suitability depends on the workload.
- There are a number of different methods to achieve the goal of capacity matching, starting with demand based workloads and using service such as auto scaling, using a queue for decoupling workloads with the simple queue service or even just appropriately sizing the instances. Sizing block storage is also key however we made this easy for you with general purpose solid state storage by default now
- Simple case of Cost optimization in AWS and most often neglicted.
- AWS managed services can save pain and massive amounts of time in provisioning, feeding and watering systems such as databases. Databases you can use the RDS service or maybe even the Redshift data warehouse where with a few clicks you can provision a database with your choice of engine and backups, monitoring, failover is all taken care of for you. There are also a number of automation services with my favourite cloudformation that allows you to define your entire environment as json structured code or use a DSL such as the popular Ruby one and automatically build out or update your entire environment
- Management of expenditure is very important, if you have a finance person to answer to, they love the ability to itemise the bill based on workload or environment and you can do this using tags or even multiple accounts. There is also a cost explorer and budgeting tool built in that gives great visibility
- Also very important for cost allocation
- dilauro@2016-11-28 – NEW SLIDE Preparations -> operations -> responses !!!
- The development process that you use for developing business logic can be the same as what you when writing CloudFormation templates. You start of with your favorite IDE or Text Editor to write the code, Eclipse, VIM or VisualStudio You then commit to template to your source code repository using your usual branching strategy and then have the template reviewed as part of your typical code review process. The template is then integrated and run as part of your CI and CD pipelines. Being simply a JSON document, you can even write Unit Tests for your templates. When developing a CloudFormation template you can use all of your normal software engineering principles At the end of the day It’s all software – a template can be reused across applications – just like code library's and a stack can be shared by multiple applications.
- The more willing and open to change and improvement you are, the easier it is to become and stay well-architected. The most important thing I did was increase team’s acceptance of change and willingness to create change. Avoid sticking with existing services, tools and processes for the wrong reasons. I find it important for people to understand loss aversion and sunk cost fallacy because this is a very common wrong reason. Avoid changing for the wrong reasons too. Don’t change just because it’s new or because everybody else is using it. Good to understand why something was introduced and people are using it. But only change because it’s going to provide long-term benefits. We started using RDS, Lambda and API Gateway, and other services because they made things simpler and easier. As you begin to adopt well-architected principles, take appropriately sized steps Know your capabilities Consider roadmap Identify biggest bang for the buck Don’t reinvent the wheel. Replaced internal tool with CloudFormation and Ansible. Then made it better by adding CodeDeploy, Lambda, and other services.
- Invest time to save time
- dilauro@2016-11-28 - Removed all resources, added https://aws.amazon.com/well-architected/ and associate screen shot. Over 100 AWS webinars are available on-demand. re:Invent slides and video are also available. Solutions Architects are in the expo. Go talk with them. Schedule some office hours to review your architecture and identify steps to make it even better.