AWS Fundamentals for System Administrators

Below are my observations and any relevant commentary with regards to the course ‘Amazon Web Services (AWS) Fundamentals for System Administrators’, which is available on Pluralsight. I’ve organized this feedback by the modules offered. The entire course is 7 hours, 19 minutes. I watched the course mostly at 1.5X speed. I did the introduction sections on 2.0x speed. If you are strong in your knowledge of the Microsoft Azure platform, you can probably jump to the section on storage. The first five sections are largely refresher answering the questions like ‘what is the cloud?’ and ‘why the cloud?’, which, if you’ve been working in Azure for any significant period of time, you’ve heard that elevator pitch before.

  • 1. Getting Started
    • a. Very basic overview of what cloud computing is and what benefits it provides.
    • b. Key Dates
      • i. AWS launched July 2002
      • ii. S3 launched in March 2006, pay just for what you use
      • iii. EC2 launched August 2006
      • iv. Google App Engine launched April 2008
      • v. Azure Beta launched in November 2009
    • c. Interesting view of the magic quadrants…Microsoft just magically appears in August 2013. I suspect this is due to Microsoft getting serious about IaaS during that time due to their very forward thinking PaaS offering having a bit of a hard time gaining traction.
    • d. If you know the definition between IaaS, PaaS, SaaS and have been following technology news in the last decade, I’d skip it.
  • 2. Introduction to AWS
    • a. This is a bit of a history lesson on AWS and a more detailed explanation of IaaS.
  • 3. What is Elastic Computing?
    • a. More explanation around the benefits of the cloud.
  • 4. Understanding AWS Global Infrastructure
    • a. Regions are …
    • b. Availability Zones are …
  • 5. Understanding AWS Security
    • a. Shared Responsibility
      • i. AWS will take responsibility for the following:
        • 1. Virtual host security
        • 2. Storage security
        • 3. Network security
        • 4. Data center security
        • 5. Database security
      • ii. Your responsibilities are:
        • 1. AWS account security (MFA, API)
        • 2. Operating System
        • 3. Database
        • 4. Applications
        • 5. Data encryption
        • 6. Authentication
        • 7. Network integrity
  • 6. AWS Free Tier
    • a. Yawn
  • 7. Working with AWS Storage: Ephemeral + S3
    • a. Differences from Azure:
      • i. You can specify Reduced Redundancy Storage at the individual file level. Azure allows you to specify the reduced redundancy only at the Storage Account Level while AWS allows this reduced redundancy at the very granular file level.
    • b. You can specify access level controls at the individual file level. Azure allows you to specify access control policies at the container level.
    • c. Azure has containers, S3 has buckets.
    • d. S3 also allows AES-256 encryption at the file level.
    • e. Versioning and events seem to be capabilities that Azure Blob Storage does not have at all.
  • 8. Working with AWS Storage: EBS + Glacier
    • a. Differences from Azure:
      • i. Azure Blob storage doubles as the storage for Azure Virtual Machine disk storage using Page blob type. EBS is a specific storage service that provides disk storage for EC2.
      • ii. EBS has different volume types (magnetic, SSD, etc.). On Azure, you have premium storage and standard storage. Premium storage uses SSD, standard storage uses magnetic.
      • iii. EBS has an OPS range of 100-4000 IOPS
      • iv. EBS has a size range of 10GB to 1024GB
  • 9. Elastic Cloud Compute (EC2)
    • a. Terminology cheat sheet:
      • i. EC2 instances: Virtual Machines
      • ii. Amazon Machine Image (AMI): Template (OVA, OVF)
      • iii. Elastic Block Storage (EBS): Volume / Hard Disk / Virtual Disk
      • iv. Ephemeral Storage: Temporary Storage
      • v. Simple Storage Service: Object-based storage
      • vi. [EC2] Elastic Compute Unit (ECU): Measure of EC2 Processor (legacy terminology)
      • vii. vCPU: Virtual CPU
      • viii. Identity and Access Management (IAM): Delegated Administration
      • ix. Elastic Load Balancer (ELB): Load Balancer
      • x. Route 53: DNS
    • b. AMI – Amazon Machine Image, Virtual Machine templates available in the Amazon Marketplace
  • 10. Understanding EC2 Pricing
    • a. On-Demand
      • i. Most expensive option
      • ii. No commitment
      • iii. Prices vary by AWS region
      • iv. Instances pricing is rounded to the nearest hour, no factional hours
      • v. Prices vary by OS:
        • 1. Linux
        • 2. RHEL
        • 3. SLES
        • 4. Windows
        • 5. Windows w/ SQL Server
        • 6. Windows w/ SQL Web
    • b. Reserved Instances (RI)
      • i. 1 year, 3 year terms can get you 30-60% savings
    • c. Spot Instances
      • i. Unused AWS capacity
      • ii. Very cheap hourly rate
      • iii. Not guaranteed
      • iv. Based on a bid
      • v. Raw processing power
      • vi. Highly scriptable
  • 11. Understanding AWS Networking, CloudWatch, and Auto Scaling
    • a. VPC Access
      • i. Internet Gateway
      • ii. Virtual Private Gateway (VPG)
      • iii. Customer Gateway (CG)
        • 1. Deployed on premise that connects to a VPG
      • iv. Direct Connect
        • 1. Dedicated & isolated VPC link
        • 2. No internet
        • 3. High Availability connectivity supported
      • v. Hardware-based VPN
        • 1. 3rd party brands supported
        • 2. Over the internet
        • 3. Higher latency than direct connect
    • b. VPC Security
      • i. VPC is region-wide but can be available across multiple availability zones within the region
      • ii. Security Groups
        • 1. Resource level traffic firewall, granular security at the instance level
      • iii. Access Control Lists
        • 1. Source & protocol filtering
        • 2. Subnet level traffic firewall (inbound / outbound rules)
        • 3. Stateless
          • a. Traffic strictly filtered
      • iv. VPC peering
        • 1. Only allowed region-wide
        • 2. IP address scheme must be different (i.e. one network can be 192.168.1.x and another must be different like 192.168.2.x)
        • 3. Same or different AWS account
    • c. Elastic Load Balancing (ELB)
      • i. Region-wide load balancer (e.g. Virtual Machine Load Balancer in Azure, NOT to be confused with Azure Traffic Manager, which can balance load across endpoints in a multitude of regions)
      • ii. Internal or external endpoints
      • iii. SSL termination and processing
        • 1. Put the SSL cert at the load balancer (the servers behind the load balancer don’t need the SSL certificate)
      • iv. ELB EC2 health checks
      • v. Route 53 performs ELB health checks
      • vi. Route 53 is AWS DNSsnip_20161108143047
      • vii. Netscalar can do cross-region load balancing
    • d. Route 53
      • i. 100% SLA
    • e. CloudWatch
      • i. Basic Monitoring
      • ii. Billing Alarms
      • iii. Notification via SES / SNS
      • iv. Custom monitoring through API
    • f. Auto-Scaling
      • i. Must have the instances configured and ‘at-the-ready’ similar to how Azure Virtual Machine scaling works
  • 12. Amazon Database Options, APIs, and Lambda
    • a. RDS
      • i. 5 different supported types
        • 1. MySQL
        • 2. Oracle
        • 3. Microsoft SQL
        • 4. PostgreSQL
        • 5. Aurora
    • b. Non-RDS
      • i. SimpleDB
        • 1. Databases < 10GB
        • 2. Managed service
      • ii. DynamoDB
        • 1. Managed service
      • iii. MongoDB
        • 1. AWS-friendly
      • iv. Couchbase
        • 1. AWS-friendly
    • c. Lambda
      • i. Event-driven compute (i.e. Azure functions)
      • ii. 2ms reaction to an event
      • iii. Thousands of functions can run in parallel
      • iv. Runs only when needed
      • v. Similar to spot instances except billing is at an extremely granular level
      • vi. Stateless
      • vii. Triggered by events
        • 1. PUT in S3
        • 2. Write to a DynamoDB table
        • 3. Transition in an EC2 instance
        • 4. Message in an SQS queue or Kinesis stream
      • viii. Common scenarios
        • 1. Server free backend
        • 2. Data triggers
        • 3. IoT
        • 4. Stream processing
        • 5. Indexing & Synchronization
      • ix. Pricing
        • 1. # of requests, $0.20 / million requests
        • 2. Execution time in 100ms
        • 3. Amount of memory
      • x. Free Tier
        • 1. 1 million requests
        • 2. 3.2 million seconds of execution
  • 13. Amazon Simple Services
    • a. SES (Simple e-mail service)
      • i. Bulk email service
      • ii. Based on number of emails sent
      • iii. Outbound only email-sending services
      • iv. Leverages amazon email reputation
    • b. SQS
      • i. Unlimited messages and queue size
      • ii. Payload up to 256KB
      • iii. Billed in chunks of 64KB payloads
      • iv. First 1M requests are free
    • c. SNS
      • i. Push messaging
      • ii. Integrates with a number of targets:
        • 1. Email
        • 2. Email-JSON
        • 3. SMS
        • 4. SQS
        • 5. HTTP/HTTPS
      • iii. Depending on the region can impact what sources are available
      • iv. You create “Topics”, you create a subscription that specifies what you want to do when the topic happens.
      • v. Topics will have an “ARN” name
        • 1. Other Amazon services allow you to supply an ARN name and select well-known event types for that specific service to trigger the event.
  • 14. CloudFront, CloudFormation, Elastic Beanstalk, CloudTrail
    • a. CloudFront
      • i. CDN
      • ii. All AWS edge locations
      • iii. Caches static content
      • iv. Proxy dynamic information (how does this work?)
    • b. CloudFormation
      • i. Automate AWS resource provisioning (i.e. Azure Resource Management Service)
      • ii. Deleting the CloudFormation deletes all instances except data
    • c. Elastic Beanstalk
      • i. Leverages CloudFormation
      • ii. PaaS services that sits on top of EC2 to host Java / .NET / PHP applications
    • d. CloudTrail
      • i. Records all API calls that happen within the account
        • 1. Identity of the caller, parameters of the call, request/response, source IP address
        • 2. SDKs, management console, command line tools, etc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s