- 1. IAM
- a. Domain
- i. Users
- 1. Represents a specific set of credentials tied to the identity of a specific user
- ii. Groups
- 1. Group of users that can have permissions or roles associated
- 2. You can’t nest groups
- iii. Roles
- 1. Defines a set of permissions for a specific resource
- 2. Rather than assign permissions to specific users / groups. You assign permissions to a role and then associate a user/group to a role.
- 3. No longer have to manipulate group membership to grant / revoke permissions
- iv. Policies
- 1. Apply policies to users, groups, and roles
- i. Users
- b. Best practice:
- i. Never use the root account
- ii. Create a new user, grant access to it and then delete the root account
- c. Setup
- i. IAM users sign-in link (to the AWS console)
- ii. You can access the console from an easier more friendly aws dashboard link
- iii. Access Keys are used by developers (API key basically)
- d. MFA
- i. Google Authenticator for multiple mobile OS platforms
- ii. Scan a barcode that is generated by AWS
- e. Signed certificates
- i. SSH is supported
- f. STS
- i. SAML
- ii. OpenID Connect
- iii. Integrate with on premise directories
- a. Domain
- 2. CloudWatch
- a. Characteristics
- i. Monitoring for AWS cloud resources
- ii. Collect and track metrics / custom metrics
- iii. Collect and monitor logs
- 1. CloudWatch log agent needs to be installed on each instance
- iv. Set Alarms
- 1. Create within the metric you’re looking at or start from scratch without the context of the metric
- 2. Actions can be triggered when an alarm takes place
- 3. Types of alarms
- a. Billing
- i. If my bill exceeds $, do something
- b. EC2
- i. Actions can be trigged by alarms:
- 1. Recover
- 2. stop
- 3. terminate
- 4. reboot the instance
- i. Actions can be trigged by alarms:
- c. Databases (RDS, DynamoDB)
- d. EBS
- a. Billing
- b. Trusted Advisor
- i. Big brother looking over your shoulder, giving you best practices and recommendations
- 1. Cost
- 2. Performance
- 3. Security
- 4. Fault Tolerance
- a. Characteristics
- 3. RDS High Availability & Load Sharing
- a. Characteristics
- i. Multiple Availability Zone deployment options
- ii. On-demand and reserve instance pricing
- iii. Magenetic, GP-SSD, or PIOPS
- b. Failover
- i. When deploying to multiple AZ, designed for HA
- ii. Synchronous replica in secondary AZ
- iii. Standby replica is invisible to you
- iv. Snapshots are taken against the standby database
- 1. Instead of affecting the master you do it to the standby
- 2. If something happens to the master, you can failover to the standby since it is synchronized
- v. Read replica can offload that load from the master since most databases are very read-intensive
- 1. You can have as many read replicas as you want
- 2. They will never be written to
- 3. Created from a snapshot off the master instance
- 4. Asynchronously replicate
- 5. Read-only disaster recovery
- a. It can still service users if both the master and standby databases are down you can still provide read-only access
- b. Some database types can promote the read replica to be the master
- c. Backups
- i. Automated backups
- 1. Backup window
- a. Start time
- b. Duration
- 1. Backup window
- ii. Manual backups
- i. Automated backups
- a. Characteristics
- 4. Backup Options
- a. EBS
- i. Point-in-time snapshots to S3
- ii. Snapshot scan be used to:
- 1. Resize volumes
- 2. Copy volumes and move them to different regions
- 3. Share volumes
- iii. Deleting snapshots only removes the data not needed by another snapshot
- b. Additional backup options
- i. VP / Direct Connect
- ii. Agent-based backup
- a. EBS
Sky Cliffs 
Pingback: AWS Certified SysOps Administrator Exam: Study Guide | Sky Cliffs