Coggle requires JavaScript to display documents.
the ability to stretch and retract infrastructure based on demand allows to pay as you go typically used during a short period of time, hours or days
the ability to build infrastructure to meet demand over a long term (days, weeks, months)
Elasticity: configure AutoScaling Group Scalability: increase instance size, use Reserved instances
Elasticity: increase/decrease IOPS based on traffic spikes Scalability: unlimited storage (automatically scales)
Elasticity: can't scale on-demand Scalability: change instance type, add number of instances
Elasticity: autoscale up/down meet varying demand Scalability: change instance type, add number of instances
AWS Auto Scaling AWS ElastiCache [Caching] Aurora [Database] RDS [Database] DynamoDB (Stream / Global Tables) Elastic IPs [VPC] S3 Cross-Region Replication [S3] SQS [Decoupling] DR DLM
AWS Auto Scaling is a simplified option to scale multiple Amazon cloud services based on utilization targets. Amazon EC2 Auto Scaling Group focuses strictly on EC2 instances to enable developers to configure more detailed scaling behaviors AWS Auto Scaling uses Amazon EC2 Auto Scaling to adjust capacity of scalable resources to handle changes in traffic or workload
Allows to configure and manage scaling for your resources through a Scaling Plan Uses dynamic and predictive scaling to scale your resources Useful for scaling applications across some AWS services: EC2 Auto Scaling Groups - increase/decrease desired capacity ECS Services - increase/decrease desired task count Spot Fleet Requests Aurora DB clusters - increase/decrease read replicas DynamoDB tables and GSI global secondary indexes - increase provisioned write/read capacity
EC2 Auto Scaling Groups - increase/decrease desired capacity ECS Services - increase/decrease desired task count Spot Fleet Requests Aurora DB clusters - increase/decrease read replicas DynamoDB tables and GSI global secondary indexes - increase provisioned write/read capacity
Application Auto Scaling allows to automatically scale scalable resources for individual AWS services beyond Amazon EC2 Application Auto Scaling supports: Target tracking scaling (CW metric), Step scaling (Alarm), Scheduled scaling There is no a specific AWS Console for Application Auto Scaling, for the supported services you work in the specific service console. Console access is not available for all resources AWS Auto Scaling uses Application Auto Scaling to adjust capacity of scalable resources to handle changes in traffic or workload
Optimize for availability - keep the average CPU utilization of your Auto Scaling groups at 40% to provide high availability and ensure capacity to absorb spikes in demand Balance availability and cost - keep the average CPU utilization of your Auto Scaling groups at 50% to provide optimal availability and reduce costs Optimize for cost - keep the average CPU utilization of your Auto Scaling groups at 70% to ensure lower costs Custom - choose your own scaling metric, target value, and other settings
CloudFormation goes through CloudFormation Stacks and find scalable resources through existing CloudFormation templates EC2 Auto Scaling Groups select one or more existing EC2 Auto Scaling Groups to be included in your Scaling Plan. The Auto Scaling Plan can override some of the EC2 Auto Scaling Group settings Tagged Resources search for scalable resources using the tags applied to them
EC2: maintain an Auto Scaling Group through launching/terminating instances DynamoDB: enable tables or secondary indexes to increase/decrease read/write capacity ECS: adjust ECS Services and Tasks in response to load variations Aurora: automatically adjust the number of read replicas in the Aurora DB Cluster (e.g. target metric of avg number of connections)
Auto Scaling Group Not Found Auto Scaling Service Not Enabled in the Account (common in Account enrolled in AWS Organization or may have active SCP preventing you) Auto Scaling config Not Working Correctly
Invalid EBS device mapping Instance Type not compatible in AZ Attempting to attach an EBS block device to an instance-store AMI Check you instance is supported in your AZ
Associated Key pair doesn't exist Security Group doesn't exist
Troubleshoot EC2 Auto Scaling Groups in the EC2 console Monitor Auto Scaling Plans in AWS Auto Scaling
Fault Tolerance - should components of my app exists in other AZs in the case of failure? Availability - Should my app be spread across multiple AZs to meet traffic demand? Cost - Could I save money by limiting the app to a single AZ?
RDS ElastiCache Redshift Neptune DocumentDB
Create EBS and apply a Tag Create new lifecycle policy (policy types) EBS snapshot policy EBS-backed AMI policy Cross-account copy event policy Target resource types (use Tags fore selection) Volume (single volume) Instance (multi-volume) Schedule details Retention type Count Age Encrypt using KMS (default and CMK) Copy tags from source (Y/N) Snapshot archiving Fast snapshot restore Cross-Region copy Cross-account sharing
EBS snapshot policy EBS-backed AMI policy Cross-account copy event policy
Volume (single volume) Instance (multi-volume)
Count Age
Encryption using KMS (default and CMK) Cross Region copy Cross-account sharing Snapshot Archiving
Does not support instance store-backed AMIs Can’t be used to manage snapshots/AMIs created outside DLM
Aurora RDS EBS Storage Gateway
FSx EFS DynamoDB EC2
Create a new EBS volume, and then copy the data on your instance store volume to the EBS volume Back up the individual files stored on an Amazon EBS volume or S3 bucket