Aws best practices
•Transferir como PPTX, PDF•
0 gostou•146 visualizações
Architecting for The Cloud Best Practices in AWS
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Aws best practices
Semelhante a Aws best practices (20)
Último
Último (20)
Aws best practices
- 1. Architecting for The Cloud Best Practices in AWS Abedulraheem Essam – firstabed@hotmail.com AWS Authorized Instructor
- 2. How much do you have experience in AWS?
- 3. Let's Start
- 4. “The Internet Operating System”
- 5. AWS Services Regions Storage Compute Networking Database Deployment
- 6. The Well-Architected Framework (WAF)
- 7. The AWS Well-Architected Framework The Five Pillars Security Reliability Cost Optimization Performance Efficiency Operational Excellence
- 8. Security Identity foundation Enabling traceability Security at all layers Protecting information and mitigating possible damage
- 9. Reliability Recover quickly from infrastructure or service failures
- 10. Cost Optimization Eliminate unneeded expense Consider using managed services
- 11. Operational Excellence Run and monitor systems , To continually improve (applications, infrastructure, policy, and operations) Deployed Updated Operated
- 12. Performance Efficiency Use computing resources efficiently to meet system requirements Select the optimal solution for each particular system (Server/Serverless or SQL/NoSQL)
- 13. The AWS Well-Architected Framework
- 14. Cloud Architecture Best Practices 1. Choose AWS Region 2. Build security in every layer 3. Leverage different storage options 4. Implement elasticity 5. Use Caching 6. Design for failure and nothing fails
- 16. AWS Global Infrastructure: Regions
- 17. Choosing a Region Restrictions, rules and compliance
- 18. Choosing a Region Proximity of users to data $$ $$ $
- 19. Choosing a Region Service and feature availability
- 20. Choosing a Region Cost Effectiveness
- 21. 2 Build Security in Every Layer
- 22. Build Security in Every Layer HTTP:80 Corporate Network EC2EC2 EC2
- 23. Build Security in Every Layer EC2EC2 EC2 Encrypt data in transit and at rest HTTPS:443 IPSEC VPN Corporate Network Key Management Service
- 24. Build Security in Every Layer EC2EC2 EC2 Enforce principle of least privilege with IAM Key Management Service HTTPS:443 IPSEC VPN Corporate Network IAM
- 25. Build Security in Every Layer EC2EC2 EC2 Create firewall rules with Security Groups and NACLs HTTPS:443 IPSEC VPN Corporate Network Key Management Service IAM
- 26. Best practices Recommendations Delete root user , Create an IAM user and Grant administrator access Activate multi-factor authentication (MFA) Rotate credentials regularly Remove unnecessary users and credentials
- 28. Leverage Many Storage Options One size does NOT fit all • Amazon S3 – object/blob store, good for large objects • Amazon CloudFront – content distribution network • Amazon Elastic Block Storage (EBS) – persistent block storage • Amazon EC2 Instance Storage – ephemeral block storage • Amazon DynamoDB – non-relational data (key-value) • Amazon RDS – managed relational database • Amazon ElastiCache – managed Redis or Memcached
- 29. Leverage Many Storage Options Current State: • All load handled by one stack • Elastic Load Balancer (ELB) • EC2 Web App cluster • Relational Database • No caching layer(s) • All persistent data in database or Web instances’ Elastic Block Storage (EBS) volumes DNS (Route 53) Web Instances Relational Database Users
- 30. Leverage Many Storage Options Offload and cache requests for static assets: • Store large/static objects in Simple Storage Service (S3) • Use a Content Delivery Network (CDN) like CloudFront to cache responses using points of presence all around the world Amazon S3 Amazon CloudFront DNS (Route 53) Web Instances Relational Database Users
- 31. Leverage Many Storage Options Save user session data in a database to avoid interrupting the user experience if a web host becomes unresponsive: • Store session/state data in DynamoDB, a managed NoSQL key-value store DynamoDB Amazon S3 Amazon CloudFront DNS (Route 53) Web Instances Relational Database Users
- 32. Leverage Many Storage Options Amazon S3 Amazon CloudFront DNS (Route 53) Web Instances DynamoDB ElastiCache Relational Database Users Cache frequent queries to shift the load off of your database: • Put ElastiCache as a caching layer between the web hosts and the database
- 35. Ways to Auto Scale Scheduled Good for predictable workloads Use case:Turning off your Dev and Test instances at night Scale based on time or day Dynamic Excellent for general scaling Supports target tracking Use case: Scaling based on CPU utilization
- 36. 5 Use Caching
- 37. Availability Zone 2 RDSDB instancestandby (multi-AZ) RDSDB instance Availability Zone 1 Elastic Load Balancing Elastic Load Balancing Auto-Scaled EC2 Instances Auto-Scaled EC2 Instances
- 38. Availability Zone 2 RDSDB instancestandby (multi-AZ) RDSDB instance Availability Zone 1 Elastic Load Balancing Elastic Load Balancing Auto-Scaled EC2 Instances Auto-Scaled EC2 Instances Amazon CloudFront S3 Bucket
- 39. Design for Failure and Nothing Fails 6
- 40. What Are We Planning? Everything fails, all the time. Large-scale events Massive eventsSmall-scale events How do we prepare for these?
- 41. Consider services and features Regions Storage Compute Networking Database Deployment
- 42. RPO and RTO Recovery Point Objective (RPO) How often does data need to be backed up? Disaster Time Example: The business can recover from losing (at most) the last 12 hours of data.
- 43. RPO and RTO Recovery Point Objective (RPO) How often does data need to be backed up? Disaster Time Example: The business can recover from losing (at most) the last 12 hours of data. RecoveryTime Objective (RTO) How long can the application be unavailable? The application can be unavailable for a maximum of 1 hour.
- 44. AZ Can Go Down
- 45. Regions Can Go Down Region 1 Region 2
- 46. How to Design for Failure?
- 47. Design for Failure: A Single User Single Points of Failure: • A single Elastic IP • Gives a server a static Public IP address • A single Amazon ElasticCompute Cloud (EC2) instance • Full stack on single host • Web application • Database • Management, etc… User AWS Cloud Elastic IP address EC2 Server Amazon Route 53 (DNS)
- 48. Design for Failure: Difficulties Scaling to Many Users We could potentially get to a few hundred to a few thousand users depending on application complexity and traffic, but… There may be difficulty scaling to many more users due to: • All eggs in one basket • No failover or redundancy Users AWS Cloud Elastic IP address EC2 Server Amazon Route 53 (DNS)
- 49. Design for Failure: Solving “All Eggs in One Basket” Separate single EC2 Server into web and database tiers: • Web Server on EC2 • Database on EC2 or RDS Amazon Relational Database Service (RDS) can take care of management overhead such as patching, backups, and failure detection Users WebServer Elastic IP address Database AWS Cloud Amazon Route 53 (DNS)
- 50. Leverage multiple Availability Zones for redundancy and high availability. • Use an Elastic Load Balancer (ELB) across AZs foravailability and failover • If using RDS, use the Multi-AZ feature for managed replication and a standby instance • If not, use failover and replication features native to your database engine Database Master Database Standby AZ 2 Design for Failure: Solving No Failover/Redundancy Users Web Server WebServer AWS Cloud AZ 1 Amazon Route 53 (DNS)
- 51. Design for Failure: Best Practices Best Practices: • Eliminate single points of failure • Use multiple Availability Zones • Use Elastic Load Balancing • Do real-time monitoring with CloudWatch • Create a database standby across Availability Zones Database Master Database Standby AZ 2 Users Web Server WebServer AWS Cloud AZ 1 Amazon Route 53 (DNS)
- 52. Design for Failure: Best Practices Best Practices: • Eliminate single points of failure • Use multiple Availability Zones • Use Elastic Load Balancing • Do real-time monitoring with CloudWatch • Create a database standby across Availability Zones Database Master Database Standby AZ 2 Users Web Server WebServer AWS Cloud AZ 1 Amazon Route 53 (DNS)
- 53. Design for Failure: Best Practices Best Practices: • Eliminate single points of failure • Use multiple Availability Zones • Use Elastic Load Balancing • Do real-time monitoring with CloudWatch • Create a database standby across Availability Zones Database Master Database Standby AZ 2 Users Web Server WebServer AWS Cloud AZ 1 Amazon Route 53 (DNS)
- 54. Design for Failure: Best Practices www.example.com Region: US West Availability Zone A Availability Zone A Route 53 provides DNS health checks X Allows for DNS Failover Region: EU (London) Availability Zone A Availability Zone A
- 55. Cloud Architecture Best Practices 1. Choose AWS Region 2. Build security in every layer 3. Leverage different storage options 4. Implement elasticity 5. Use Caching 6. Design for failure and nothing fails
- 56. The End
Notas do Editor
- First we'll talk about some of the goals of the design principles in the Well-Architected Framework. If you would like to have some assistance with well architected design: The AWS Well-Architected Tool is a self-service tool that provides you with on-demand access to current AWS best practices. It is designed to help architects and their managers review AWS workloads at any time, without the need for an AWS Solutions Architect. This service is based on the AWS Well-Architected Framework, which was developed to help cloud architects build secure, high-performing, resilient, and efficient application infrastructure. You can review the state of your workloads and compare them to the latest AWS architectural best practices.
- Security deals with protecting information and mitigating possible damage. Your architecture will present a much stronger security presence by implementing some basic security measures, like implementing a strong identity foundation, enabling traceability, applying security at all layers, automating security best practices, protecting data in transit and at rest For more information, see https://d1.awsstatic.com/whitepapers/architecture/AWS-Security-Pillar.pdf
- Ensuring reliability can be difficult in a traditional environment. Issues arise from single points of failure, lack of automation, and lack of elasticity. When applying the ideas of the reliability pillar, you will be able to prevent many of these issues. Properly designing your architecture in respect to high availability, fault tolerance, and overall redundancy will be helpful for you and your customers. For more information, see https://d1.awsstatic.com/whitepapers/architecture/AWS-Reliability-Pillar.pdf
- Cost optimization is an ongoing requirement of any good architectural design. The process is iterative and should be refined and improved throughout your production lifetime. Understanding how efficient your current architecture is in relation to your goals will ultimately help with removing unneeded expense. Consider using managed services as they operate at cloud scale and can offer a lower cost per transaction or service. For more information, see https://d1.awsstatic.com/whitepapers/architecture/AWS-Cost-Optimization-Pillar.pdf
- When creating a design or architecture, you must be aware of how it will be deployed, updated, and operated. It is imperative that you work towards defect reductions and safe fixes and enable observation with logging instrumentation. In AWS, you can view your entire workload (applications, infrastructure, policy, governance, and operations) as code. It can all be defined in and updated using code. This means you can apply the same engineering discipline that you use for application code to every element of your stack. For more information, see https://d1.awsstatic.com/whitepapers/architecture/AWS-Operational-Excellence-Pillar.pdf
- When considering performance, you want to maximize your performance by using computation resources efficiently and maintain that efficiency as the demand changes. It is also important to democratize advanced technologies. In situations where technology is difficult to implement yourself, consider using a vendor. In implementing the technology for you, the vendor takes on the complexity and knowledge, freeing your team to focus on more value-added work. Mechanical sympathy: Use the technology approach that aligns best to what you are trying to achieve. For example, consider data access patterns when you select database or storage approaches. For more information, see https://d1.awsstatic.com/whitepapers/architecture/AWS-Performance-Efficiency-Pillar.pdf
- AWS is steadily expanding its global infrastructure to help customers who want to ensure that their data resides only in the region they specify and to achieve lower latency and higher throughput. As you and all customers grow your businesses, AWS will continue to provide infrastructure that meets your global requirements. The isolated GovCloud (US) Region is designed to allow US government agencies and customers to move sensitive workloads into the cloud by addressing their specific regulatory and compliance requirements. AWS products and services are available by region so you may not see all regions available for a given service. You can run applications and workloads from a region to reduce latency to end users while avoiding the up-front expenses, long-term commitments, and scaling challenges associated with maintaining and operating a global infrastructure.
- Our data will be subject to the laws of the country and locality in which it's stored. In addition, some laws dictate that if you're operating your business in their jurisdiction, you cannot store that data anywhere else. Similarly, compliance standards (such as the United States’ Health Insurance Portability and Accountability Act, or HIPAA) have strict guidelines on how and where data can be stored. Also, AWS opened its first carbon-neutral region in 2011 and now offers five separate carbon-neutral regions. Take all of these things into account when evaluating where to place your environment. To find more information about carbon-neutral options, see https://aws.amazon.com/about-aws/sustainability.
- Proximity is a big factor in choosing your region, especially when latency is critical. In most cases, the latency difference between using the closest region and the farthest region is relatively small, but even small differences in latency can impact customer experience. Customers expect responsive environments, and as time goes by and technology becomes more and more powerful, those expectations rise as well.
- While AWS strives to make our services and features available everywhere, the complications that arise from having a global reach make accomplishing that goal extremely challenging. But rather than wait until a service is available everywhere before launching it, we release our service when it's ready, and expand its availability as soon as possible.
- Service costs can differ depending on which region they're used in. For example, an Amazon EC2 instance in US-East 1 may not cost the same as if it were running in EU-West 1. Typically, the difference in cost may not be enough to supersede the other three considerations—however, in cases where the latency/compliance/service availability differences between regions are minimal, you may be able to save by using the lower-cost region for your environment. In circumstances where your customers are in different areas of the globe, consider optimizing their experience by replicating your environment in multiple regions that are closer to them. Since you would then be distributing your load across multiple environments, your costs for components in each environment may go down even as you add more infrastructure. For example, adding a second application environment might allow you to cut your processing and storage capacity requirements in half in each environment. Since AWS is designed to allow you that kind of flexibility, and since you only pay for what you use, you could easily scale your existing environment down as a way to mitigate the cost of adding another environment. The downside to that approach is that you now have two environments to manage, and not all of your components will scale down enough to mitigate all of the new component costs. Additionally, you may have to maintain one single storage "source of truth" in one region (such as a Master RDS instance), with which your secondary region would have to communicate with, increasing latency and cost for those operations.
- IAM best practices Delete your access keys for the AWS account root user, because they provide unrestricted access to your AWS resources. Access keys are long-term credentials for an IAM user or the AWS account root user. You can use access keys to sign programmatic requests to the AWS CLI or AWS API (directly or by using the AWS SDK). Access keys consist of two parts: an access key ID (for example, AKIAIOSFODNN7EXAMPLE) and a secret access key (for example, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY). Similar to a user name and password, you must use both the access key ID and secret access key together to authenticate your requests. Manage your access keys as securely as you do your user name and password. Instead, use IAM user access keys or temporary security credentials. Activate multi-factor authentication (MFA) on your AWS credentials to add another layer of protection to help keep your account secure. Create IAM users and give them only the permissions they require. Do not use your AWS account credentials for day-to-day interaction with AWS, because the AWS account root user provides unrestricted access to your AWS resources. Use IAM groups to assign permissions to your IAM users to simplify managing and auditing permissions in your account. Apply an IAM password policy to require your IAM users to create strong passwords and to rotate their passwords regularly. Use roles for applications that run on Amazon EC2 instances. Delegate by using roles instead of by sharing credentials. Rotate credentials regularly. Remove unnecessary users and credentials. Use policy conditions for extra security. Monitor activity in your AWS account. For more information, see http://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html.
- What kind of disaster are you planning for? A small-scale event where you simply need to get a restoration and backup? A larger-scale event where multiple resources are impacted? A colossal scale event where multiple people and resources will be impacted? Disaster recovery (DR) is about preparing for and recovering from a disaster. Any event that has a negative impact on a company’s business continuity or finances could be termed a disaster. This includes hardware or software failure, a network outage, a power outage, physical damage to a building like fire or flooding, human error, or some other significant event. To minimize the impact of a disaster, companies invest time and resources to plan and prepare, to train employees, and to document and update processes. The amount of investment for DR planning for a particular system can vary dramatically depending on the cost of a potential outage. Companies that have traditional physical environments typically must duplicate their infrastructure to ensure the availability of spare capacity in the event of a disaster. The infrastructure needs to be procured, installed, and maintained so that it is ready to support the anticipated capacity requirements. During normal operations, the infrastructure typically is under-utilized or over-provisioned. With AWS, your company can scale up its infrastructure on an as-needed, pay-as-you-go basis. You get access to the same highly secure, reliable, and fast infrastructure that Amazon uses to run its own global network of websites. AWS also gives you the flexibility to quickly change and optimize resources during a DR event, which can result in significant cost savings.
- Recovery point objective (RPO) is the acceptable amount of data loss measured in time. For example, if a disaster occurs at 12:00 PM (noon) and the RPO is one hour, the system should recover all data that was in the system before 11:00 AM. Data loss will span only one hour, between 11:00 AM and 12:00 PM (noon).
- Recovery time objective (RTO) is the time it takes after a disruption to restore a business process to its service level, as defined by the operational level agreement (OLA). For example, if a disaster occurs at 12:00 PM (noon) and the RTO is eight hours, the DR process should restore the business process to the acceptable service level by 8:00 PM. A company typically decides on an acceptable RPO and RTO based on the financial impact to the business when systems are unavailable. The company determines financial impact by considering many factors, such as the loss of business and damage to its reputation due to downtime and the lack of systems availability. IT organizations then plan solutions to provide cost-effective system recovery based on the RPO within the timeline and the service level established by the RTO.
- AWS is available in multiple regions around the globe, so you can choose the most appropriate location for your DR site, in addition to the site where your system is fully deployed. It’s highly unlikely for a region to be unavailable. But if some very large-scale event impacts a region—for instance, a meteor strike—it is within the realm of possibility. AWS maintains a page that inventories current services offered by region (products and services by region). AWS maintains a strict region isolation policy so that any large-scale event in one region will not impact any other region. We encourage our customers to take a similar approach to their multi-region strategy. Each region should be able to be taken offline with no impact to any other region. If you have an AWS Direct Connect (DX) circuit to any AWS Region in the United States, it will provide you with access to all regions in the US, including AWS GovCloud (US), without that traffic going through the public internet. Also consider how applications are deployed. If you deploy to each region separately, you can isolate that region in case of disaster, and transfer all your traffic to another region. If you are deploying new applications and infrastructure rapidly, you may want to have an active-active region. Let’s say you deploy something that causes a region's applications to be unavailable or misbehaving. You can remove the region from the active record set in Route 53, identify the root cause, and roll back the change before re-enabling the region.
- AWS is available in multiple regions around the globe, so you can choose the most appropriate location for your DR site, in addition to the site where your system is fully deployed. It’s highly unlikely for a region to be unavailable. But if some very large-scale event impacts a region—for instance, a meteor strike—it is within the realm of possibility. AWS maintains a page that inventories current services offered by region (products and services by region). AWS maintains a strict region isolation policy so that any large-scale event in one region will not impact any other region. We encourage our customers to take a similar approach to their multi-region strategy. Each region should be able to be taken offline with no impact to any other region. If you have an AWS Direct Connect (DX) circuit to any AWS Region in the United States, it will provide you with access to all regions in the US, including AWS GovCloud (US), without that traffic going through the public internet. Also consider how applications are deployed. If you deploy to each region separately, you can isolate that region in case of disaster, and transfer all your traffic to another region. If you are deploying new applications and infrastructure rapidly, you may want to have an active-active region. Let’s say you deploy something that causes a region's applications to be unavailable or misbehaving. You can remove the region from the active record set in Route 53, identify the root cause, and roll back the change before re-enabling the region.
- AWS is available in multiple regions around the globe, so you can choose the most appropriate location for your DR site, in addition to the site where your system is fully deployed. It’s highly unlikely for a region to be unavailable. But if some very large-scale event impacts a region—for instance, a meteor strike—it is within the realm of possibility. AWS maintains a page that inventories current services offered by region (products and services by region). AWS maintains a strict region isolation policy so that any large-scale event in one region will not impact any other region. We encourage our customers to take a similar approach to their multi-region strategy. Each region should be able to be taken offline with no impact to any other region. If you have an AWS Direct Connect (DX) circuit to any AWS Region in the United States, it will provide you with access to all regions in the US, including AWS GovCloud (US), without that traffic going through the public internet. Also consider how applications are deployed. If you deploy to each region separately, you can isolate that region in case of disaster, and transfer all your traffic to another region. If you are deploying new applications and infrastructure rapidly, you may want to have an active-active region. Let’s say you deploy something that causes a region's applications to be unavailable or misbehaving. You can remove the region from the active record set in Route 53, identify the root cause, and roll back the change before re-enabling the region.
- If you have stringent SLAs or your application demands the fastest possible failover; please consider adding global accelerator into your architecture. Global Accelerator provides your network with greater resiliency by removing the role of DNS in failover. It can protect your users and applications from caching issues and allows nearly instantaneous redirection of traffic to healthy endpoints. Additionally, when you add new endpoints into your architecture, they can receive traffic immediately without waiting for DNS propagation. Global accelerator uses Static IP addresses that are Anycast from multiple AWS edge locations giving us a fixed entry point address that enables ingress of user traffic at an edge location closest to them