aws exam cram Flashcards
S3 standard
“Multi-AZ, single region
- durability: 99.999999999% (eleven 9s)
- availability: 99.9%”
S3 object storage classes
"- standard - intelligent tiering - infrequent access - one-zone infrequent access - glacier - glacier deep archive "
S3 standard IA
“Good for infrequently accessed data
Multi-AZ, single region
- durability: 99.999999999% (eleven 9s)
- availability: 99.9%
lower cost of storage, but has an
additional cost of $0.01/GB retrieved”
Glacier
"Cold storage Eleven 9s of durability Much less expensive than hot storage Retrieval time varies based on retrieval options: - expedited: < 5 minutes - standard: 3-5 hours - bulk: 5-12 hours"
S3 one-zone IA
“Good for infrequently accessed data when you can trade off cost for reduced availability
Single AZ, so only 99.5% available
Less expensive than S3 IA; designed for eleven 9s of durability within a single AZ (if AZ is destroyed, data will be lost)”
S3 lifecycle policies
“Can transition objects from standard to IA to Glacier after a certain period (restrictions apply – for instance, an object can’t be transitioned to glacier less than 30 days after it is transitioned to IA)
Transitions follow a waterfall model: standard -> IA -> intelligent tiering -> one-zone IA -> glacier -> glacier deep archive
Costs are associated with transitions to glacier.
Can delete objects after a certain number of days; different tiers have requirements for how long objects must be stored; early deletion can result in charges for the entire minimum period”
Glacier deep archive
"Cold storage Eleven 9s of durability Less expensive than glacier Retrieval time varies based on retrieval options: - standard: 12 hours - bulk: 48 hours"
S3 versioning
“With versioning enabled on a bucket, overwriting an object generates a version ID for the object; old versions are preserved.
Deleting an object on a version-enabled bucket creates a delete marker; old versions are still preserved.
Can retrieve old versions of objects using their IDs.
Must use a lifecycle policy to prevent infinite proliferation of objects.”
S3 lifecycle policies - minimum storage durations
”- Standard: none
- Standard IA: 30 days
- One-zone IA: 30 days
- Intelligent tiering: 30 days
- Glacier: 90 days
- Glacier Deep Archive: 180 days”
S3 transfer acceleration
“Use CloudFront to speed up transfer to/from S3 (there is a cost associated with this)
Transfer Acceleration Speed Comparison tool can tell you how much speedup to expect.”
S3 object lock
“Available for all storage classes
Retention policies:
- governance: no one can delete during retention period unless they have special privileges
- compliance: no one can delete during retention period, not even root account
Legal hold: once put on an object, the object can’t be deleted until the hold is removed”
S3 static websites
”- enable web hosting
- set permissions
- create index document
optionally:
- configure redirects
- custom error document
- enable web traffic logging
Really should use CloudFront in front of the site”
S3 events
“Can be routed to:
- SNS topic
- SQS queue
- Lambda function”
EFS storage classes
”- Standard
- Infrequent access (reduced cost, higher latency, charge for R/W ops)
“
S3 security best practices
”- block public access
- avoid policies with wilcard identities or wildcard actions
- apps should use IAM roles to access S3 buckets (don’t include credentials in apps)
- MFA delete - requires MFA to delete a bucket to prevent accidental deletions
- aws:SecureTransport - requires all connections to use TLS when accessing bucket contents
- use VPC endpoints to keep traffic to/from S3 inside your VPC”
EFS throughput
”- bursting: volume builds up crediets based on the filesystem size; credits allow bursting for limited time periods
- provisioned: good for high I/O small filesystems (so you don’t have to overprovision the storage space)”
EFS performance mode
”- general purpose (7K iops)
- max I/O (more throughput and iops, but more latency)”
EFS encryption
“Encryption at rest supported via AWS-managed keys
EFS supports encryption of data in transit; use the -o tls mount option”
Mounting EFS
”- use /etc/fstab inside of linux VMs
- use the EFS mount helper, which simplifies the process by automatically editing /etc/fstab”
AWS Data Sync
“Uses a super-efficient, purpose-built data transfer protocol that can run 10 times as fast as open source data transfer.
Can sync to S3 or EFS across the Internet or via Direct Connect, and can also sync from AWS to data stored on-premises.
Can be used for DR replication
Run an agent in your datacenter to perform the data transfer”
Importing data to AWS
”- Snowball
- Snowmobile
- Kinesis Data Firehose
- S3 Transfer Acceleration
- AWS Storage Gateway
- AWS DataSync”
Snowmobile
100PB of storage capacity housed in a 45-foot long High Cube shipping container that measures 8 foot wide, 9.6 foot tall and has a curb weight of approximately 68,000 pounds. The ruggedized shipping container is tamper-resistant, water-resistant, temperature controlled, and GPS-tracked.
Snowball
“Physical device shipped to your location; comes in 50TB and 80TB sizes (slightly less usable)
Snowball variants also exist for edge storage and edge computing, combining storage and vCPUs.”
Disaster recovery strategies
”- Backup/restore
- Pilot light
- Warm Standby
- Multisite”
Storage Gateway
“Hybrid cloud storage solution running on an on-prem VM or hardware appliance
Caches data locally, providing low-latency disk and network performance for your most active data, with optimized data transfers AWS in the background
Supports S3, Glacier, and EBS
Data encrypted in transit and at rest in AWS.”
RPO
“Recovery Point Objective
Gap between the last transaction preserved and the time of the failure (represents the length of time for which transations were lost)
- Backup/restore: time since last backup, typically 24 hours
- Pilot light: time since last snapshot, maybe 4-12 hours
- Warm standby: time since last database write
- Multisite: time since last database write”
RTO
“Recovery Time Objective - amount of time service can be offline
- Backup/Restore: 8-24 hours
- Pilot light: 4-8 hours
- Warm standby: < 4 hours
- Multisite: seconds”
EC2 Compute-optimized instance types
“Nitro-based:
- C6g: Graviton2
- C5: Intel
- C5a: AMD
- C5n: Intel + faster network
Non-nitro based:
- C4
“
EC2 general-purpose instance types
“Nitro-based:
- A1: AWS Graviton processors (ARM)
- T*: burstable (accumulate burst credits)
T4g: Graviton2, T3: Intel, T3a: AMD - M6g: Graviton2
- M5: Intel
- M5a: AMD
- M5n: Intel + higher network
Non-nitro based:
- T2: Intel
- M4: Intel
”
EC2 Accelerated computing
“Hardware acccelerators
- P3: Intel + GPU
- P2: Intel + GPU
- Inf1: AWS Inferentia
- G4: Intel + GPU
- G3: Intel + GPU
- F1: Intel + FPGA”
EC2 Memory-optimized instance types
“Nitro-based:
- R6g: Graviton2
- R5: Intel
- R5a: AMD
- R5n: Intel + faster network
- X1e: high frequency Intel; up to 3TB RAM
- X1: high frequency Intel; up to 2TB RAM
- High Memory: 6, 9, 12, 18, 24TB of RAM
- z1d: custom Xeon (up to 4GHz); local NVMe
Non-nitro based:
- R4”
Nitro
“Underlying virtualization infrastructure for current-gen EC2 instances.
Uses hardware cards to offload functions like VPC, EBS, Instance Storage, and security.
Security chip handles sensitive virtualization and security functions in a locked down security model preventing all administrative access (including Amazon employees)
Lightweight hypervisor that manages memory and CPU to deliver performance close to bare metal.
”
EC2 Storage-optimized instance types
”- I3: Intel + NVMe
- I3en: like I3 with enhanced networking
- D2: up to 48TB of HDD local storage
- H1: up to 16TB of HDD local storage”
Inferentia
“AWS custom silicon for deep learning.
Supports up to 128 TOPS with up to 16 chips per Inf1 instance.”
Graviton
“Custom Arm-based processor designed to provide optimal price-performance ratio.
1st gen in A1 instances, Graviton2 in *g instances with local NVMe storage”
Enhanced networking
“Use Elastic Network Adapter (ENA) to support network speeds of up to 100 Gbps
Available on current gen instances (introduced in mid-June 2016)
AMI requires special tagging to indicate it supports ENA
No additional fee to use it
”
EC2 instance lifecycle
“INSTANCE LIFECYCLE DIAGRAM
- billed only for running (and for stopping if hibernating)
- instance stays in running state while rebooting”””
EBS optimized
“EBS optimized instances deliver dedicated bandwidth to EBS.
When attached to an EBS-optimized instance, gp2 volumes are designed to deliver their baseline and burst performance 99% of the time; provisioned iops volumes 99.9% of the time
Newer instance types enabled EBS optimization by default. Some older instance types offer it as an option, with an associated hourly fee.”
Placement group
“Placement groups influence the placement of a group of interdependent instances:
- cluster: packs instances close together in an AZ for low-latency network performance
- partition: spreads instances across logical partitions so that instances in a partition don’t share underlying hardware with instances in another partition
- spread: strictly paces a small group of instances across underlying hardware to reduce correlated failures”
EC2 burstable instance types
“T2, T3, T3a, T4g
Burstable instances earn a set rate of CPU credits per hour, depending on the instance size.
A CPU credit allows for 100% utilization of a CPU core for one minute.
For example, a t3.nano earns 6 credits per hour. So it can run at 100% CPU for 6 minutes as long as it is entirely idle for 54 minutes. But it could run at 10% for the entire hour.
”
EC2 user data
“Small chunk of data (16KB max) that must be base64-encoded
Can be used to pass two types of data:
- shell scripts (starts with “”#!””)
- cloud-init directives (starts with ““#cloud-config””)
Shell script is run as root and output logged to /var/log/cloud-init-output.log
Cloud-init directives are similar, but they have some high-level constructs that can be used to update packages, etc.
Cloud-init is the mechanism by which your ssh keys are installed on instances”
EC2 metadata
“Instance metadata is data about your instance that you can use to configure or manage the running instance. Instance metadata is divided into categories, for example, host name, events, and security groups.
You can also use instance metadata to access user data that you specified when launching your instance.
Metadata can be accessed inside the instance at
http://169.254.169.254/latest/meta-data/”
EC2 AMIs
”- EBS-backed:
- stored as EBS snapshot (with associated costs)
- instances using the AMI will use it on EBS root volume
- created using AMI tools
- Instance store-backed:
- stored in S3 (with associated costs)
- instances using the AMI will use it on an instance store volume
- created with a single command/call”
EC2 pricing models
”- On-Demand: expensive, no commitment
- Spot instances: cheapest, not dependable
- Reserved instances: cheaper, with commitment
- Savings plans: similar to RI, but more flexible
“
EC2 instance store
“An instance store provides temporary block-level storage for your instance. This storage is located on disks that are physically attached to the host computer.
This storage is ephemeral; it is deleted when the instance is stopped or terminated. It is also lost if the underlying drive fails.
Note: when EC2 was first introduced, all AMIs were backed by instance store. After EBS was introduced, AMIs could be backed by EBS. This is the preferred technique now; they launch faster (instance store requires full image to be retrieved from S3 before it can start; EBS-backed AMIs can lazy load; performance after startup can be a little slower than with instance store)
Modern instance types don’t support instance store as the root device.
But you can still attach instance store volumes for things like /tmp or cache directories.”
EC2 Reserved Instances
”- up-front payment in exchange for lower prices
- 1-year or 3-year commitment
- tied to specific instance types (often in a specific AZ)”
EC2 On-Demand
”- most expensive
- no up-front payment
- no commitment”
EC2 Savings Plans
”- optional up-front payment
- 1-year or 3-year commitment
- more flexible than reserved instances
- doesn’t save as much as reserved instances”
EC2 Spot instances
”- pay market rates
- extremely cheap
- instances can be unreliable”
EC2 root volumes
”- Instance store:
- when stopped or terminated, the volume is destroyed
- size limit of 10GB
- launches slower (AMI has to be fully copied from S3 to instance store)
- no cost for root volume
- EBS
- when stopped, volume persists
- when terminated, volume is destroyed unless DeleteOnTermination=false
- size limit of 16TB
- launches faster (AMI is lazy-loaded; there could be a performance impact for some period after startup)
- charged for EBS volume usage while running (or while stopped)”
EC2 Dedicated Instances
”- physical EC2 server dedicated to your use
- can be important for compliance
- can also help with server-bound software licenses like SQL Server
- can be purchased on-demand or with reservation”
EBS volume types
“SSD:
- io1: provisioned iops: 50 iops/s/GB, up to 1000 MB/s
- io2: provisioned iops with 99.999% durability, 500 iops/s/GB, up to 1000MB/s
- gp2: general purpose: 3 iops/s/GB, up to 250 MB/s
io2 pricing is the same as io1; only thing io1 has over io2 is multi-attach (which is on the roadmap); so there is little reason to use io1 today
HDD:
- st1: throughput optimized; uses burst model; up to 500MB/s per volume
- sc1: cold HDD; uses burst model; up to 250MB/s per volume; cheapest type”
EBS
“Elastic Block Store
- Block storage for EC2 instances
- replicated within an AZ
- 99.999% availability
- 99.8 - 99.9% durability (except io2, which has 99.999% durability)”
EBS encryption
“Seamless encryption of EBS data volumes, boot volumes and snapshots, eliminating the need to build and manage a secure key management infrastructure.
EBS encryption enables data at rest security by encrypting your data volumes, boot volumes and snapshots using Amazon-managed keys or keys you create and manage using the AWS Key Management Service (KMS).
In addition, the encryption occurs on the servers that host EC2 instances, providing encryption of data as it moves between EC2 instances and EBS data and boot volumes.”
EBS snapshots
“point-in-time snapshots of your volumes to Amazon S3.
Snapshots are stored incrementally: only the blocks that have changed after your last snapshot are saved, and you are billed only for the changed blocks
Snapshots can be read directly via APIs, or you can restore them into EBS volumes; these EBS volumes use lazy-loading so that they come online almost immediately
Can use snapshots to resize EBS volumes; just restore the snapshot to a larger EBS volume (requires application and OS support).”
EBS elastic volumes
Elastic Volumes allows you to dynamically increase capacity, tune performance, and change the type of any new or existing current generation volume with no downtime or performance impact.
EBS: Data Lifecycle Manager for EBS snapshots
“automated way to back up data stored on EBS volumes by ensuring that EBS snapshots are created and deleted on a custom schedule. No scripts or external applications required.
Tag EBS volumes and create Lifecycle policies for creation and management of backups.
Use Cloudwatch Events to monitor your policies and ensure that your backups are being created successfully.”
ELB
“An Elastic Load Balancer distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, IP addresses, and Lambda functions.
It can handle the varying load of your application traffic in a single Availability Zone or across multiple Availability Zones.”
S3 encryption
“Encryption at rest:
- server-side encryption: have S3 encrypt the object before saving
- SSE-S3: let S3 manage the keys
- SSE-KMS: use customer master keys stored in KMS
- SSE-C: encrypt with customer-provided keys
- client-side encryption
Encryption in transit:
- use TLS”
Autoscaling policies
“Types:
- Target tracking scaling—Increase or decrease the current capacity of the group based on a target value for a specific metric. (RECOMMENDED)
- Step scaling—Increase or decrease the current capacity of the group based on a set of scaling adjustments, known as step adjustments, that vary based on the size of the alarm breach.
- Simple scaling—Increase or decrease the current capacity of the group based on a single scaling adjustment.
Can apply more than one policy; AWS will resolve conflict by applying the policy that requests the larger number of instances (duing scale-out and scale-in)”
EC2 autoscaling groups
“A collection of EC2 instances treated as a logical group for purposes of scaling
Scaling can be manual, automatic based on a schedule, or automatic using one or more autoscaling policies
Can launch on-demand instances or spot instances (or both)
The group can span availability zones; if multiple AZs are specified, the instances will be spread across the AZs.”
Autoscaling: step scaling
“Scaling can be specified for how much a CloudWatch alarm is breached.
For example, imagine a CloudWatch alarm on CPU usage with a breach threshold of 50%
Scale-out policy:
0-10%: 0% change, 10-20%: 10% change, 20-50%: 30% change
Scale-in policy:
0-10%: 0% change, 10-20%: - 10% change, 20-50%: - 30% change
at 75% CPU, ASG will scale up by 30% (75 - 50 = 25)”
Autoscaling: simple scaling
“The original scaling model for AWS Autoscaling groups
When a CloudWatch alarm triggers, the group is scaled out; another alarm is configured to trigger the scale in
”
