Skip to content

Instantly share code, notes, and snippets.

@selcukcihan

selcukcihan/aws-solutions-architect-pro-exam_notes.md

Last active December 18, 2024 05:52
Show Gist options
  • Save selcukcihan/b33484cae52bc0a3fe1c067e8662d985 to your computer and use it in GitHub Desktop.
Save selcukcihan/b33484cae52bc0a3fe1c067e8662d985 to your computer and use it in GitHub Desktop.
Download ZIP
Cheat sheet for AWS Solutions Architect Professional Exam
Raw
aws-solutions-architect-pro-exam_notes.md

AWS Solutions Architect Professional Exam Notes

Data Storage

  • Persistent stores: glacier, RDS

  • Transient stores: SQS, SNS

  • Ephemeral stores: EC2 instance, Memcached

  • IOPS: how fast we can read/write

  • Throughput: how much data can be moved at a time

  • ACID consistency: atomic, consistent, isolated, durable transactions

  • BASE consistency: basic available: data presented even if stale, soft-state: might not be consistent instantly, eventual consistency

S3

  • 2nd service after SQS historically
  • Object store
  • Max size is 5TB but single put max 5GB
  • Use multipart upload for larger than 100MB
  • A KEY is not a file path
  • Security
    • Resource based (object ACL, bucket policy)
    • User based (IAM policies)
    • Optional multi-factor auth before delete
  • Versioning, enables rollback and undelete (delete marker), old versions count billable size until permanently deleted, integrated with lifecycle
  • Cross region replication: security, compliance and latency may require cross region replication.
    • buckets can be in separate accounts
    • destination can be in different region or same region
    • use batch replication for existing objects, because it's not handled automatically for you
    • versioning must be enabled for both source & dest
  • Storage classes:
    • Standard
    • Standard IA (infrequent access)
    • One zone IA (non-critical data, single AZ)
    • Reduced redundancy
    • Intelligent tiering: Has archive as well (moves to glacier or glacier deep arch), not to be confused with lifecycle management
    • Glacier: long term archiving with retrieval times ranging from minutes to hours
    • Glacier Deep Arch: Within 12 hours
  • Lifecycle management: optimize costs, adhere to retention policies, rules on prefix, tags or current vs prev versions
  • Analytics: athena, redshift, quicksight. Quicksight is a self-service business intelligence solution
  • Streaming: IOT, kinesis firehose
  • ML: rekognition, Lex, MXNet
  • Storage class analysis: analyze access pattern to optimize
  • Encryption:
    • SSE-S3: use S3's existing encryption key for AES-256
    • SSE-C: upload your own key
    • SSE-KMS: use key managed by AWS KMS
    • Client-Side: encrypt on the client before uploading (PGP, GPG etc)
  • Transfer acceleration: speed up uploads using CloudFront
  • Requester pays
  • Tags: assign tags for costing, billing, security etc.
  • Events: Trigger SNS, SQS, Lambda
  • Static web hosting
  • BitTorrent: publicly available objects can have this

Amazon Glacier

Archive solution.

  • Glacier vault like S3 bucket
  • Archives, like S3 objects
  • Policies:
    • Policy: defines what rules vault must obey by
    • Access: Through IAM
  • Glacier vault lock: immutable
  • Once uploaded to vault you can't update, you can upload a new version or delete it but it's immutable
  • Vault lock: you have 24 hours to confirm or abort the lock, once confirmed it's archived and can't be changed and is safe.
  • Cheap, slow, seldom accessed cold storage
  • Used by AWS Storage Gateway Virtual Tape library
  • Integrated with AWS S3 via Lifecycle management
  • Faster retrieval speed options if you pay more
  • Glacier is a separate AWS Service with own API

Amazon EBS

Elastic block storage. Think virtual hard drives, can only be used from EC2.

  • Tied to single AZ.
  • Choices for optimized IOPS, throughput and cost
  • Supports snapshots
  • Pay for all the blocks you've allocated
  • Instance stores are temporary, only available when EC2 is running.
  • Instance stores are fast, no network latency.
  • EBS requests still go through the network.
  • EBS volumes can be attached/detached.
  • Snapshots
    • cheap and easy, you can have a cloudwatch rule to take snapshots
    • makes easy to share data sets
    • migrate a system to a new AZ or Region
    • Convert unencrypted volume to encrypted volume
    • Snapshots are differential (incremental)
    • Since it's differential it's cost effective so you can have frequent snapshots
    • When restoring, goes through all the diffs
    • If old snapshot is deleted you can still restore later snapshots
    • Snapshot lifecycle policy

Amazon EFS

Elastic file service. This is NFS as a service.

  • Elastic storage capacity, pay for what you use (contrast to EBS)
  • Multi AZ
  • Configure mount points in one or many AZs
  • Can be mounted from on premise but need a very fast & stable internet connection like Direct Connect.
  • Can only be mounted from Linux EC2 instances and not windows
  • NFS by itself is not a secure protocol, so use a secure tunnel or VPN connection
  • Amazon Data Sync:
    • purpose built protocol to keep storage on-prem in sync with EFS or S3 over a Direct Connect or the internet and it is secure.
    • also supports EFS to EFS Sync in case you want to keep multiple EFS shares in sync.
  • EFS is 3x expensive than EBS, 20x more than S3.

Amazon Storage Gateway

  • virtual machine that can run on prem with VMWare or HyperV or special configured Dell hardware
  • Provides local storage resources backed by AWS S3 and Glacier.
  • Often used in disaster recovery preparedness to sync to AWS.
  • Useful in cloud migration
  • Different functions:
    • File Gateway: NFS, SMB interfaces. Allow on-prem or EC2 to store objects in S3 via NFS or SMB mount point. Data then gets replicated to S3.
    • Volume Gateway Stored Mode: iSCSI interface, async replication of on-prem data to S3.
    • Volume Gateway Cached Mode: iSCSI, primary data stored in S3 with frequent access data cached locally on-prem
    • Tape Gateway: iSCSI, virtual media changer and tape library for use with existing backup software.
  • Enables bandwidth savings?

Amazon WorkDocs

Dropbox

  • Secure fully managed file collab service
  • Has web mobile and native clients (no linux)
  • can integrate with AD for SSO
  • HIPAA ISO etc compliant
  • SDK available for creating complementary apps

Database on EC2

  • Run any db with full control on EC2
  • Must manage all things like backups and redundancy, patching etc.
  • Consider this if you require a db not supported yet by RDS (like SAP HANA for instance)

RDS

  • MySQL, maria, postgres, sql server microsoft, oracle, mysql compatible aurora
  • automated backups, patching etc. with maintenance windows
  • push-button scaling, replication and redundancy
  • Use S3 for blobs, RDS is not suitable for that
  • For auto scaling, use dynamodb instead of RDS
  • RDS supports multi AZ and read replicas
  • MySQL: non-transactional storage engines like MyISAM don't support replication, must use InnoDB (or XtraDB on Maria)
  • MariaDB is open-source fork of MySQL
  • Replication:
    • Multi-AZ implementation replication between master and standby is synchronous. As soon as a transaction is committed, it's instantly replicated to other standbys.
      • If master fails, standby can become the master automatically
    • Read replicas are async replication, lagging behind somewhat (seconds only)
      • If whole region fails, we can promote a read replica but this is somewhat a big deal and may need manual attention.
      • After promotion, reconfigure the single AZ to multi AZ so the (now) master is now multi AZ
  • Multi-AZ is strictly for failover, standby instance cannot be read from by an application. When doing failover, it's automatically handled, no need for updating DNS or endpoints.
  • Read replicas are for performance improvements and migrations.
  • After promoting a read replica, need to change the CNAME records set in Route 53 to the new endpoint.
  • We can have a read replica in another region.
  • Read replica shows as a separate DB identifier on RDS with its own endpoint which is different from the master db.
  • Creating read-replica does not cause any down time.
  • After promoting a read replica to master, you need to make that DNS switch.
  • If running a single AZ, you may get a performance hit when the backup job kicks in.

DynamoDB

  • Multi AZ
  • Eventual consistency
  • Cross region replication
  • Can request strongly consistent read
  • Priced by throughput
  • Dynamodb does not scale down after autoscaling
  • Alternatives is on-demand capacity, scaled up and down with a small premium cost vs calculating what you need as capacity
  • DDB transactions for ACID compliance
  • Global secondary index: partition key & sort key can be different from the main index.
  • Local secondary index: same partition key as the table, but a different sort key. This needs to stay local and respect the table's partition key.
  • We can use global secondary indexes as a way of replication by using the same partition key and sort key.
  • The global secondary index can have a different RCU/WCU limit than the main table.
  • Replica is eventually consistent, so global secondary index can't guarantee strong consistency.
  • DAX (accelerator) works as an in-memory cache in front of DynamoDB to improve read performance.

Amazon Redshift

  • Fully managed clustered petabyte scale data warehouse
  • Postgres compatible with JDBC & ODBC drivers
  • Compatible with most BI tools
  • Cost effective as compared to other on-prem dwh platforms
  • Parallel processing & columnar data store optimized for complex queries
  • Query directly from data files on S3 via Redshift Spectrum.

Amazon Neptune

  • Fully managed graph db
  • Supports open graph APIs for Gremlin and SPARQL

Amazon Elasticache

  • Choose from redis and memcached

  • Push-button scalibility for memory writes and reads

  • In memory key/value store, not persistent in the sense of dynamodb

  • Use redis for web session store

  • db caching, use memcache in front of AWS RDS

  • Leaderboards for instance would be suitable for caching.

  • Think memcache as more lower level and not fancy, simple. If you need to

    • scale out/in as demand changes
    • run multiple CPU cores and threads
    • cache objects (db queries)

  • Think redis as the fancy option, if you need

    • encryption
    • HIPAA compliance
    • clustering
    • complex data types
    • high availability (replication)
    • pub/sub
    • geospacial indexing
    • backup and restore

  • You have some persistance options with redis, but it's a cache so treat it as such, it's not meant to be persistent.

Other DB options

  • Athena on S3 based on Presto
    • query raw data, json, csv
    • convert to parquet format for performance
    • similar to redshift spectrum but
      • want to join S3 data with existing tables in Redshift then use Redshift spectrum
  • Amazon Quantum Ledger DB
    • based on blockchain
    • provides immutable journal
    • centralized design allows for higher performance and scalibility
    • append only
    • running tally that is immutable
  • Amazon Managed Blockchain
    • true blockchain distributed framework supports ethereum, hyperledger fabric.
    • uses QLDB ordering service to maintain history of transactions
  • Amazon Timestream Database
    • for time-series data, fully managed
    • alternative to dynamodb or Redshift, includes built-in analytics like interpolation and smoothing
  • Amazon DocumentDB
    • with mongodb compatibility
    • AWS invention that emulates mongo API
    • fully managed with KMS, scalable backup etc
    • choose this if you use mongo but don't want to manage the servers
  • Amazon Elasticsearch
    • ES: elasticsearch
    • search engine
    • stores as documents like json
    • ELK stack: elastic, logstash, kibana
    • Intake: IoT, CloudWatch, Firehose instead of logstash

DB Comparisons

DB Type Properties
DB on EC2 * control over everything
* choose if DB not available with RDS
RDS * traditional relational db for OLTP
* data is well-formed & structured
DynamoDB * key/value pair data or unpredictable structure
* in-memory performance with persistence
Redshift * massive data
* primarily for OLAP workloads
Neptune * relationships between objects a major portion of data value
Elasticache * fast temporary storage for small data
* highly volatile data

Networking

Reinvent 2021 Networking Foundations

  • VPC: your private network within an AWS region.
  • Each region has at least 3 AZs (Availability Zones)
  • Your us-east-1a might be different from my us-east-1a, they are assigned randomly when you create an AWS account.
  • You can use AZ IDs to correlate and have everything on the same AZ.
  • Subnets within VPC are bounded by AZ.
  • You can have multiple subnets within an AZ.
  • EC2 are attached to a subnet via elastic network interface ENI.
  • You can assign CIDR /16 down to /28 to your VPC. Once you set your VPC IP you can't change it.
  • Then you can assign subnet CIDRs, same as VPC /16 to /28.
  • You can attach multiple ENIs to an instance.
  • 5 reserved private IPs:
    • 10.0.0.0: VPC base
    • 10.0.0.2: Route 53 Resolver
      • 10.0.1.0: Network address
      • 10.0.1.1: VPC router
      • 10.0.1.2-3: reserved
      • 10.0.1.255: network broadcast
  • You can assign public IPs, with elastic IPs you can change it later but with auto assignment you can't change it after EC2 is created.
  • Instance MetaData Service: IMDS: you can query this service to get the public IP of your EC2 instance within that instance.
  • IPV6:
    • v6 VPCs are /56, subnets are /64
    • v6 addresses are global unicast addresses

VPC Routing

  • Each VPC subnet must be associated with a subnet route table.
  • When a subnet is created, by default it's associated with the VPCs default route table.
  • The default route table contains routes for the local CIDRs of the VPC.
  • A subnet can be associated to a single route table, but the same route table can be associated to multiple subnets.
  • Route tables control traffic leaving a subnet.
  • Each subnet has a VPC router, that handles inter VPC connectivity between subnets.
  • VPC router is a soft router, no physical device.
  • Local services:
    • IMDS (metadata service): provides metadata like IAM role, IP etc.
    • Amazon Time Sync Service: provides NTP endpoints
    • Amazon Route 53 Resolver

Security

  1. Traffic across instance network interface (security groups)
  2. Traffic across subnet (NACLs)
  3. Traffic across VPC boundary (Internet Gateway)
Security Groups
  • Security groups are stateful firewalls around instances (ENIs actually)
  • By default inbound rules deny all inbound traffic
  • Stateful, so outbound packet is automatically allowed if inbound rule permits (no need to cover ephemeral ports)
  • EC2 instances can be associated with security groups, autoscaling groups can be associated as well.
  • Rules can refer to IP addresses, prefix lists or security groups, both as source or destination
  • You can have your db servers in a particular security group (to allow db connections) also another security group for web servers.
  • The security groups can refer to each other, for instance web server security group would allow outbound traffic to the db server security group.
NACLs
  • Security at the subnet level
  • Stateless packet filtering, so you need to define rules on both directions.
  • By default allows all traffic in/out the VPC
  • Each subnet must be associated with a NACL and a NACL can be associated to multiple subnets.
  • Rules can only refer to IP addresses.
Internet Gateway

IGW provides 1-1 network address translation between private addresses in v4 and public addresses on the internet.

To access a resource in a VPC from the internet, 5 things must hold:

  1. Resource should have a public IP
  2. Security Group (SG) should allow traffic
  3. NACLs should allow
  4. Attach an Internet Gateway (IGW) to the VPC
  5. Route to the IGW
NAT Gateway
  • For private instances in private subnets, you can have a NAT Gateway so that those instances can access the internet, for instance to download a software update.
  • NAT Gateway is for outbound traffic only.
  • NAT Gateways are created within subnets.
  • Private EC2 => NAT Gateway => Internet Gateway is how the traffic flows
  • Only for IPv4 addresses.
Egress-Only Internet Gateway
  • NAT Gateway for IPv6
  • 1 per VPC (like IGW)
  • Outbound only connectivity (like NATGW)
VPC Peering
  • VPCs should not have overlapping CIDR ranges
Transit Gateway

Scalable!

  • Virtual Router to have 1000s of VPCs to be inter-connected.
  • Attachment: TG can be attaced to a VPC, Direct Connect or VPN
  • Route table: Comes with default route table, but you can have multiple tables with static and dynamic entries and the next hop is one of those attachments.
  • Association: Associate a route table with an attachment
VPC Interface Endpoints
  • To privately access to AWS services from your VPC.
  • You create an interface endpoint in your subnet.
  • Built-on AWS PrivateLink
  • S3 & DynamoDB use Gateway Endpoints (similar to Interface Endpoints) but different because you need to update your subnet route table to add routes to public IPs for S3 and dynamodb, whereas with VPC Interface endpoints this is automatic.
  • VPC endpoint policy: IAM resource policy, for the endpoint itself so that the endpoint can access S3 for instance.
AWS PrivateLink
  • Consumer side: consumer VPCs (your customers)
  • Service provider side: your application, your service to serve multiple clients
  • Customers can create endpoints in their VPCs and then access your application.
  • Your app is known as the "endpoint service", this is typically a network load balancer
  • Private Link extends across regions, so you can use it to offer your service to customers in other regions.
Hybrid connectivity
Direct Connect
  • High speed connectivity between your on-prem and AWS
  • Dedicated link, with a physical ethernet cable
  • Can connect to AWS services like S3 or VPC
  • Up to 100Gbps in certain locations
  • Has 2 virtual interfaces:
    • public for S3.
    • private for your VPCs and private resources in AWS.
  • You need a Direct Connect Gateway to extend your single virtual interface connection to multiple VPCs in multiple regions.
  • Virtual private gateway: Entry into your private VPC, like an aggregator of Direct Connect connections.
  • You can have at most 10 virtual private gateways attached to your Direct Connect Gateway. They are attached via private VIFs (virtual interfaces).
  • If you want more scale, you need Transit Gateway which comes with a special type of private virtual interface called the transit VIF.
AWS Site-to-Site VPN

IP-Sec VPN connections. 3 Concepts:

  1. Customer Gateway: AWS resource of your side of the VPN connection
  2. Connection: 2 IPSec VPN tunnels back and forth
  3. VPN aggregator: On AWS side, such as AWS Transit Gateway or a Virtual Private Gateway. Virtual Private Gateway is per VPC, not scalable in that sense.
AWS Client VPN
  • Fully managed elastic and secure TLS connection from any location
  • Supports split tunneling
  • Supports many clients as well as an vended AWS client

Load Balancing

Elastic Load Balancing
  • Application Load Balancer (ALB) (layer 7): targets IP, instance, AWS Lambda. Terminates flows. Listener: HTTP/S, gRPC. Front end: Virtual IP
  • Network Load Balancer (layer 4): targets IP, instance, ALB. Terminates flows. Listener: TCP, UDP, TLS. Front end: Virtual IP
  • Gateway Load Balancer (3rd party appliances, layer 3 gateway + layer 4 load balancing): Targets IP, instance. Transparent pass through. Listener: IP. Route table entry.

You need to choose at least two AZs (subnets). So network interfaces are created automatically in those subnets that represent the load balancer.

Route 53 Resolver for VPC

  • Amazon provided DNS: reachable on three addresses (two IPv4, 1 IPv6)

  • DNS Host names: private DNS name and a resouce based private DNS name which has the instance ID on it. Finally a public DNS name if you need it public.

  • You create an outbound resolver endpoint to reach your on premise DNS resolver.

  • Reverse is also true, you can create an inbound resolver endpoint so that your on-prem DNS resolver can forward DNS queries to the Route 53 Resolver.

  • Private Hosted Zones: Hosted zone is a collection of records that are associated with one or more VPCs.

  • Private hosted zones are for private domains specifically.

  • Private Hosted Zones provide DNS services to VPCs but cannot be access from the internet. They can be associated with VPCs either by the console, CLI or programmatically via SDK.

AWS Global Accelerator

  • Provides performance and improves reliability and availability, if your app is global across multiple AWS regions.
  • When global accelerator is enabled, AWS gives you two static IPs, any cast. These two IPs are within two fault tolerant and isolated network zones without any overlap in physical infra.
  • Accelerator can point to individual EC2 instances, ALB or an NLB.

CloudFront

  • Concepts:
    • Origin: like S3 for instance, authoritative source of data
    • Distribution: comes with its own domain name, points to an origin

Security

  • DDoS: AWS Shield provides DDoS prevention. Standard: no additional charge. Advanced: subscription based, 24/7 access to shield team and also cuts cost for traffic due to DDoS.
  • AWS WAF: web app firewall, protect http/s traffic to select AWS services. Allow lists, block lists or just accounting. WAF is free for Shield Advanced customers.
  • Network Firewall: Cloud native stateful flexible managed network firewall.
  • Route 53 can log DNS queries it receives. Also provides a DNS firewall. Using resolver endpoints, you can also achieve the same capabilities of the DNS firewall for your on-prem DNS resolvers.
  • VPC flow logs: info about IP traffic passing through network interfaces in your VPC. Athena + CloudWatch log insights can help you analyze logs.
  • VPC Traffic mirroring: to receive actual packets, copies packets from ENI of an instance and forwards to whatever destination you need.

Amazon GuardDuty

Continuous security monitoring service provides threat detection and anomaly detection. Low cost, high value, easy to enable.

  • VPC flow logs
  • DNS logs
  • CloudTrail events
  • S3 Data plane events

  • Unicast vs multicast. AWS does not allow multicast messages because it would affect other tenants.

  • ICMP: protocol used by network devices

  • Reserved IP addresses in VPCs, example: 10.0.0.0/24 (32 - 24 => 2^8 => range contains 256 addresses)

    • 10.0.0.0: network address
    • 10.0.0.1: reserved by AWS for VPC router
    • 10.0.0.2: reserved by AWS for DNS
    • 10.0.0.3: reserved by AWS future use
    • 10.0.0.255: VPCs don't support broadcast, so AWS reserves this address

  • Example: 192.168.8.16/28: (32 - 28 => 4 => 2^4 => range contains 16 addresses) reserved: 192.168.8.16, 17, 18, 19, 31, usable: 192.168.8.20 up to 192.168.8.30

  • When you create an account, your account is assigned logical names for AZs. Your US-WEST-2A might be different from another account's US-WEST-2A

  • This is done to distribute load equally, also for security reasons.

Connectivity

AWS Managed VPN

  • AWS managed IPsec VPN over your existing internet
  • Quick and simple way to create secure tunnel to a VPC, redundant link for Direct Connect or other VPC VPN.
  • Supports static routes, BGP peering and routing
  • Dependent on your internet connection

To create it,

  • you have a virtual private gateway on AWS and a designated appliance on your on-prem such as a router to act as the customer gateway.
  • create VPN connection in AWS and download config for your customer gateway.

Direct Connect

  • Dedicated network connection over private lines right into AWS backbone.
  • Require a big pipe into AWS.
  • Pros: more predictable performance, up to 10Gbps provisioned connections, supports BGP peering & routing
  • Cons: may require additional telco and hosting provider relationships and or new network circuits
  • It's not redundant, so advised to create a backup VPN connection or a second direct connect connection.

Direct Connect Plus VPN

  • IPsec VPN over private lines
  • Want added security of encrypted tunnel
  • Pros: more secure
  • Cons: complexity increased

VPN CloudHub

  • Link remote offices
  • Reuses existing internet connection
  • assign multiple customer gateways to a virtual private gateway

Software VPN

  • Provide your own VPN endpoint and software
  • Must manage both ends of the connection for compliance reasons, or if need to use a VPN option not support by AWS
  • Provides the most flexible solution
  • Cons: design for redundancy on your part

Transit VPC

  • For connecting geographically disperse VPCs
  • Locations and VPC-deployed assets across multiple regions that need to communicate
  • similar to software vpn in terms of flexibility and management

VPC to VPC

  • VPC Peering:
    • AWS provided network connectivity between 2 VPCs
    • uses AWS backbone without touching the public internet
    • A => B and B => C, does not imply A => C (transitive peering not supported)
    • need to make a VPC peering request and other party should accept
    • CIDR ranges can't overlap
  • PrivateLink
    • AWS provided network connectivity between VPCs and or AWS services using interface endpoints
    • keep private subnets truly private by using AWS backbone
    • redundant: uses AWS backbone
    • more granular than VPC peering, operates at the service granularity instead of the whole network
    • Interface endpoint: elastic network interface with private IP, secured by security groups, uses DNS entries to redirect traffic, all services use this (API gateway, cloudwatch etc)
    • Gateway endpoint: Uses prefix lists in route table to redirect traffic, secured by VPC endpoint policies, only two SERVICES: S3 & DynamoDB

Internet Gateways

Provide internet access to your VPCs.

  • Internet Gateway
  • Egress-only internet gateway
  • NAT instance
  • NAT Gateway

Internet Gateway

  • Horizontally scaled, redundant, highly available component with no bandwidth constraint
  • If your subnet is associated with a route to the internet, then it's a public subnet
  • Supports IPv4 and IPv6
  • Purposes:
    • provide route table target for internet-bound traffic
    • perform NAT for instances with public IP addresses (does not perform NAT for instances with private IPs only, the instance should have a public IP to access the internet)
  • The VPC IPv4 CIDR block can be from /16 to /28.

Egress-only Internet Gateway

  • IPv6 are globally unique and therefore public by default
  • provides outbound internet access for IPv6 addressed instances
  • prevents inbound access to those instances
  • stateful: forwards traffic from instance to internet and then sends back response
  • must create a custom route for ::/0 to the egress-only internet gateway
  • use egress-only internet gateway instead of NAT for IPv6
  • only outbound, prevents inbound access to those instances

NAT instance

  • EC2 instance running a special AWS provided AMI
  • Translate traffic from many private IPs to a single public IP and back
  • Does not allow public internet initiated connections into private instances
  • not supported for IPv6
  • NAT instance must live on public subnet with route to internet gateway
  • private instances in private subnet must have a route to the NAT instance, usually default route destination of 0.0.0.0/0

NAT Gateway

  • managed NAT
  • must create in public subnet
  • uses elastic IP for public IP
  • private instances in private subnet must have a route to the NAT instance, usually default route destination of 0.0.0.0/0
  • created in specified AZ with redundancy in that zone
  • for multi-AZ redundancy, create NAT Gateways in each AZ with routes for private subnets to use the local gateway
  • up to 5Gbps can scale up to 45Gbps
  • Can't use NAT Gateway to access VPC peering, VPN or Direct Connect, so make sure to include specific routes to those in the route table (most specific route is selected first)
  • can't associate security groups with the NAT Gateway (as opposed to NAT instance)
  • Elastic IP can't be detached

Routing

  • VPCs have an implicit router and a main routing table
  • You can modify the main routing table or create new tables
  • Each table contains a local route for the CIDR block
  • Most specific route for an address wins

BGP (Border Gateway Protocol)

  • Popular routing protocol for the internet
  • required for direct connect, optional for VPN
  • Alternative is to use static routes
  • Runs on port 179 and also requires ephemeral ports
  • Autonomous System Number (ASN) = Unique endpoint identifier
  • You can assign weights to routes (local) and higher weight is preferred path for outbound traffic

Enhanced Networking

  • Enables high performance networking compared to traditional virtual interfaces.
  • May need to install driver if not using Amazon Linux AMIs
  • Two drivers:
    • Intel 82599 VF Interface: 10Gbps
    • Elastic Network Adapter: 25Gbps

Placement Groups

To arrange our instances physically

  • Clustered: instances placed on the same rack, low latency high throughput, limited capacity
  • Spread: instances spread across to limit risk of failure, can span multiple AZs, max 7 per group per AZ
  • Partition: Grouped into partitions and spread across racks, reduced risk, better for large distributed workloads, not supposed for dedicated hosts

Route53

  • What's a DNS
  • DNS record types (A, CNAME, MX, TXT)
  • Concepts (alias, hosted zone)
  • Routing policies:
    • simple: simple
    • failover: health checks and failover to another
    • geolocation: route to nearer to you
    • geoproximity: AWS region proximity, also supports bias weights to favor a certain region
    • latency: depending on latency to the resource
    • multivalue: several IP addresses, like a basic load balancer
    • weighted: routed according to the percentage of weight assigned

CloudFront

  • If you want to use your custom domain, you need a custom SSL certificate.
  • Can have wildcard subdomain
  • SNI: allows client to specify which host to connect to, so the server can serve different certificates based on the request
  • Or you can pay for a dedicated IP address for each edge location if you can't do SNI for some reason (old browsers do not support it, like opera on symbian)

Elastic Load Balancer

  • Distribute inbound connections to one or many backend endpoints
  • Three options:
    • Application load balancer (layer 7): deals with http/https
    • Network load balancer (layer 4): operates at TCP layer
    • Classic load balancer (layer 4 or 7): discouraged, old
  • Can be used for public or private workloads
  • Consume IP addresses within a VPC subnet, make sure you have enough addresses
  • They can autoscale
  • All three has zonal failover, health checks, cross-zone balancing, cloudwatch metrics, ssl offloading and resource based IAM permissions
  • Classic can do TCP and HTTP but not UDP, only NLB can do UDP
  • ALB can do path or host based routing whereas others can't
  • ALB and NLB can do websockets, CLB can't
  • ALB & NLB can do SNI, CLB can't
  • All can do sticky sessions
  • Only ALB can do user auth
  • NLB supports static IP addresses.
  • ALB with Global Accelerator can be used to get static IP addresses for your app endpoints in a single or multiple AWS regions.
  • The target type of existing target groups cannot be changed from "instance" to "IP"

Routing

  • NLB can route based on port number
  • ALB can route based on
    • host
    • path
    • http headers
    • http methods
    • query string parameters
    • source IP
  • NLB is fast and performant whereas ALB is flexible and powerful in terms of routing

Security

  • Shared responsibility model: customer responsible for security in the cloud
  • Principle of least privilege
  • Temporary permissions, give when needed only, short-lived

Federated security models

  • SAML
    • can handle both authorization & authentication
    • XML based protocol
    • Can contain user, group membership and other useful info
    • best suited for single sign-on for enterprise users
  • OAuth
    • allow sharing of protected assets without the need to send login credentials
    • handles authorization only, not authentication
    • issues token to client
    • app validates token with authorization server
    • best for API authorization between apps
    • delegate access, allowing client apps to access info on behalf of user
  • OpenID Connect
    • Identity layer on top of OAuth, adds authentication
    • uses rest/json msg flows
    • supports web clients, mobile, js clients, extensible
    • best for single sign-on for consumer
  • AWS Artifact in AWS Console has a lot of reports for compliance, you can check the various compliance related stuff there.

Multi-Account Management

  • Large orgs need multiple accounts for segregation, cost allocation etc.
  • Many ways to achieve segregation:
    • AWS Organizations
    • Service control policies
    • Tagging
    • Resource groups
    • Consolidated billing
  • You can have an org where a separate account exists for consolidated billing, this would enable economies of scale and may provide savings
  • Service control policies cascade down the tree of sub accounts.
  • SCPs are available only in an organization that has all features enabled. SCPs aren't available if your organization has enabled only the consolidated billing features
  • You can also use service control policies to blacklist certain AWS services such as preventing users to change IAM roles or CloudTrail settings.
  • SCPs alone are not sufficient to granting permissions to the accounts in your organization. No permissions are granted by an SCP.

Network Controls & Security Groups

  • Security groups
    • are virtual firewalls for individual assets (ec2, rds etc)
    • control inbound/outbound traffic for TCP/UDP/ICMP protocols
    • work with port or port ranges
    • inbound rules are by source IP, subnet or other security group
    • outbound rules are by destination IP, subnet or other security group
  • Network Access Control Lists (NACLs)
    • are additional layer of security for VPC that acts as firewall
    • apply to entire subnets rather than individual resources
    • default NACL allows all inbound & outbound traffic
    • are stateless, no concept of a connection
    • can duplicate or further restrict access along with security groups
    • remember ephemeral ports for outbound if needed
  • NACLs provide a backup method to have more confidence in case a security group is misconfigured and is too permissive. Covers entire subnet so new resources are also subject to the NACL, this may help with if you forget to assign the proper security group when creating the resource.

AWS Directory Services

  • Cloud Directory: cloud-native dir to share and control access to hierarchical data between apps
  • Cognito
  • Directory Service for Microsoft Active Directory: runs on windows server 2012 R2
  • AD Connector: if you already have an AD on-prem, users can log into AWS services, also allows EC2 instances to join AD domain.
  • Simple AD: low scale, low cost AD based on Samba, best for if you need a simple user directory or LDAP compatibility
AD Connector Simple AD
* must have existing AD
* existing AD users can access assets via IAM roles
* supports MFA		 * stand-alone AD based on Samba
* supports user accounts/groups/policies/domains
* kerberos based SSO
* MFA not supported
* no trust relationships

Credential & Access Management

  • AWS Security Token Service is useful, grants credential access to apps or users.
  • The credentials can be sources from IAM or federated options
  • Cognito mostly for mobile apps
  • AWS Secrets Manager: store passwords, encryption keys, api keys, ssh keys, pgp keys and fully integrated with IAM

Encryption

  • KMS (key management service): generate keys for encryption
  • CloudHSM: dedicated hw device, single tenanted, must be in a VPC, does not natively integrate with AWS services like KSM
    • classic: safeNet Luna SA (upfront cost $5000), need another device for high availability
    • Current: proprietary device, no upfront cost, pay per hour, clustered
  • AWS Certificate Manager
    • managed service to provision, manage deploy public/private SSL/TLS certificates
    • directly integrated into many services like CloudFront, ELB, APIGateway
    • free public certs to use with AWS, no need to register via 3rd party authority
    • you can import 3rd party certificates
    • supports wildcard domains
    • managed renewal

Distributed Denial of Service Attacks

  • Minimize attack surface: NACLs, SGs, VPC design
  • Scale to absorb: Auto-Scaling groups, CloudFront, static web content via S3
  • Safeguard exposed resources: Route 53, AWS WAF (web app firewall) or AWS Shield
  • Learn normal behaviour: GuardDuty, CloudWatch

IDS & IPS (intruder detection/prevention)

  • CloudWatch logs events across services, think operations
  • CloudTrail logs API activity, more low-level and more granular
  • Both can log from multiple accounts
  • CloudWatch can store logs indefinitely, CloudTrail stores to S3 or CloudWatch
  • CloudWatch alarms have 14 days, after that they drop. CloudTrail has no native alarming, can use CloudWatch.

Service Catalog

  • Framework allowing admins to create pre-defined products for users
  • Granular control over who has access to which offerings
  • Makes use of adopted IAM roles, this makes it very easy to manage
  • Allows end-users to be self-sufficient
  • Based on CloudFormation templates
  • Admins can version and remove products, existing running product versions won't be shutdown.
  • Constraints:
    • launch constraint: IAM role that the catalog assumes when an end-user launches a product
    • notification constraint: can get notifications when products are launched or have problems
    • template constraint: adjust product attributes based on choices a user makes, helps narrow allowable values an end-user can select (instance types for ec2 for instance)
  • Multi-account: another account can reuse (shared catalog), configs and such are propogated to the consuming account, but users/groups/roles are not!

Migration

  • Hybrid: On-prem + cloud
  • VMware vCenter: transparent migration of VMs to AWS.

Cloud Adoption Framework

Has 6 components

  • Business: create a strong business case for cloud adoption. Ability to measure ROI/TCO
  • People: evaluate org roles/structures, new skills and process needs and identify gaps. Career management aligned with evolving roles and necessary training options.
  • Governance: project management, align with KPIs etc
  • Platform: resource provisioning, arch patterns adjusted to leverage cloud-native, new app development skills and processes enable more agility
  • Security: IAM modes change, logging/audit, shared responsibility model is a shift in mindset
  • Ops: monitoring, performance management, business continuity, disaster recovery etc. takes on new methods in the cloud

Server Migration Service

  • Automates migration of on-prem vmware (vsphere) or microsoft (hyper-v) virtual machines
  • replicates VMs by creating AMIs and syncs volumes
  • minimizes cutover downtime by syncing VMs incrementally
  • supports Windows and Linux VMs only (like AWS)
  • Server migration connector is downloaded as a virtual appliance into your on-prem vSphere or Hyper-V steup.

Database Migration Service

  • DMS + Schema Conversion Tool (SCT) helps migrate dbs to AWS RDS or EC2 based dbs.
  • SCT can copy db schema for same db migrations, or it can convert schemas when migrating to a different db.
  • DMS for smaller simpler conversions
  • SCT for larger, complex datasets like data warehouses.
  • DMS has replication function for on-prem to AWS or to Snowball or S3.
  • DMS can move data between SQL, NoSQL & text based targets
  • DMS does not support DB2 as a target.
  • With DMS no downtime on the source DB while migrating

Application Discovery Service

  • Gathers info about on-prem data centers to plan for the migration
  • Collects config, usage and behaviour data from your servers to help estimate TCO (total cost of ownership) to run on AWS
  • Can run as agent-less (VMware env) or agent-based (non-VMware)
  • AWS Migration Hub bundles these services on the console

Network Migrations and Cutovers

  • Ensure your IPs do not overlap between VPC and on-prem
  • 5 IPs are reserved in every VPC subnet!
  • Most start with a VPN to AWS
  • Then switch to Direct Connect, keep VPN as a backup
  • Transition from VPN to Direct Connect seamlessly using BGP (border gateway protocol)
  • Once Direct Connect is up, configure both VPN and Direct Connect within the same BGP prefix.
  • Make sure Direct Connect is the preferred route from your network to AWS and not VPN (through BGP weighting or static routes)

Snow Family

  • AWS import/export: ship external drive to AWS and someone plugs it in and copies your data to S3
  • AWS Snowball: Box that AWS ships to you, copy over up to 80TB and ship back
  • AWS Snowball Edge: Same as Snowball but with onboard Lambda and clustering
  • AWS Snowmobile: Shipping container full of storage (up to 100PB) and a truck to transport it.
    • Delivery truck with data
    • For massive data, this is faster and more cost effective
    • It's a device, encrypted at rest and in transit

Architecting to Scale

Auto Scaling

  • EC2 Auto Scaling: scale out, horizontal scaling

    • maintain: keep minimum number of instances running
    • manual: set max and min or specific number, manually change the desired capacity via cli or console
    • schedule: scale out/in based on a schedule
    • dynamic: based on real-time metrics

  • Application Auto Scaling: Single API for managing scalability of all components of an app, like DynamoDB, ECS, EMR.

    • target tracking policy: I want my ECS hosts to stay at or below 70% cpu utilization
    • step scaling policy: Whenever I add a new set of 10K connections on my ELB, I want to increase my EC2 spot fleet by 20%
    • scheduled scaling policy: Every friday evening, increase my dynamodb table RCU to 20K units.

  • AWS Auto Scaling: Birds eye view, console that can manage both EC2 and app level auto scaling

  • To use EC2 auto scaling, you need launch configuration and specify vpc and subnets for new instances.

  • You can attach to ELB and define a health check.

  • Health check grace period: time allowed for new instances to become online, before the health check starts checking them

  • Cooldown period: not supported for scheduled scaling, automatically applies to dynamic scaling, optionally to manual scaling as well.

  • Cooldown gives your resources time to stabilize before automatically triggering another scaling event. Default cooldown period is 300 seconds. You can override the default period value.

  • Cooldown is like: add an instance, wait some time to see if it was enough, if not enough add another one etc.

  • AWS Predictive Scaling: automatically scale based on historical data

Kinesis

  • Streaming data processing

  • 500 shards limit, but can be increased unlimited by requesting an increase

  • Each shard is able to ingest 1000 records per second

  • Each record consists of a partition key, sequence number and data blob (max 1MB)

  • Transient data store, default retention is 24 hours, can be configured up to 7 days

  • Sequence numbers are unique within a shard, can be duplicated across shards

  • Use the sequence number to determine the newness of a record within a shard

  • Kinesis Data Streams & Kinesis Video Streams

  • Kinesis Firehose

    • to direct the data to destinations like S3, Redshift, Amazon Elasticsearch, api gateway, splunk, etc.
    • ITL (ingest, transform, load) solution

  • Kinesis Data Analytics: serverless fully managed Apache Flink, allows to do analytics on the data as it comes in, without the need to send it to a data warehouse

DynamoDB Scaling

  • Max item size is 400KB
  • Throughput is specified in terms of RCU and WCU
  • Partition calculations:
    • by capacity: (Total RCU / 3000) + (Total WCU / 1000)
    • by size: Total Size / 10GB
    • Total partitions: Round up for MAX(By capacity, By size)
  • Auto-scaling based on a target tracking policy, you can have a separate policy for the global secondary index
  • On-demand scaling
    • is a bit more expensive than traditional scaling or auto-scaling for dynamodb, you pay a bit of a premium for the luxury.
    • useful if you have no idea what your load will be or you can't deal with scaling lag
    • instantly allocated capacity as needed with no concept of provisioned capacity.
  • Dynamodb Accelerator:
    • microsecond response time
    • in memory cache, good for read heavy workloads
    • bad for write-heavy workloads
    • sits between the client and dynamodb

SNS

  • Pub/Sub
  • Topic: channel for publishing
  • Subscription: clients subscribe to topics
  • Endpoint protocols: HTTP, Email, SMS, SQS, Amazon Device Messaging & Lambda
  • You can do fan-out architecture
  • For loosely coupled architectures

SQS

  • Integrated with KMS for encryption
  • Transient like Kinesis, default 4 days max 14 days retention
  • Supports first in first out
  • Max msg size is 256KB, but using Java SQS SDK you can have messages up to 2GB (stores in S3)
  • Standard queue: order of delivery not guaranteed, at least once delivery
  • FIFO: if a message gets an error all the messages behind it will be stuck, which introduces a delay/latency
  • Amazon MQ
    • Implementation of Apache ActiveMQ
    • fully managed and highly available
    • Supports ActiveMQ API, JMS, NMS, MQTT and Websocket
    • Designed as a drop-in replacement for on-prem message brokers
    • For new apps, choose SQS!

AWS SAM

  • Serverless application model
  • Has a CLI, with local testing and debugging lambdas
  • You write YAML
  • Open source framework for building serverless apps
  • Extension of CloudFormation, it generates cloudformation behind the scenes

Simple Workflow Service (AWS SWF)

  • Status tracking system
  • Create distributed async systems as workflows
  • Best for human-enabled workflows like order fulfillment
  • Supports both sequential and parallel processing
  • Not recommended for new apps, use Step Functions!
  • Has two building blocks:
    • activity worker: program that you write to perform tasks
    • decider: program that controls coordination of tasks such as ordering, scheduling and concurrency
  • The programs need to do long polling to ask for work, so it's not like they are triggered

Step Functions & Batch

  • Amazon State Language: json to define step functions
  • AWS Batch:
    • manage workflows on EC2 instances
    • Choose compute: managed, unmanaged, spot, on-demand, vCPUs
    • create job definition: script, json, env variables, mount points, IAM role, container image etc
  • Remember that when there's a manual intervention AWS steers customers towards the SWF (tip for the exam)

Elastic Map Reduce (EMR)

  • Managed hadoop framework for processing big data
  • Supports Apache Spark, HBase, Presto and Flink
  • Step: programmatic task to process data (count words)
  • Cluster: collection of EC2 instances provisioned by EMR to run your steps
  • Collection of several opensource projects, easy to use
  • Hadoop HDFS: file system data is stored in for analytics
  • MapReduce: actual framework that processes the data
  • ZooKeeper: resource coordinator

Business Continuity

  • RTO: recovery time objective, how much time it takes to go back online
  • RPO: recovery point objective, where in history can we tolerate to recover data from

Disaster Recovery Modes

  • Backup & restore: Minimal config, least flexible, analogous to off-site backup storage
  • Pilot light: minimal footprint kept on AWS kind of a standby, just waiting for disaster to happen. It's a cost effective hot-site. Requires manual intervention, must keep AMIs up to date with on-prem.
  • Warm standby: more responsive, more costly, resources still need to be scaled for production load. Can be used as a shadow environment for testing or staging.
  • Multi-site: best way to ensure we have minimal down-time. Ready to take full production load. Fails over in seconds, no or little intervention. Most expensive disaster recovery option.

Storage options

  • EBS:
    • failure rate less than 0.2% per year
    • availability target of 99.999%
    • replicated automatically within a single AZ
    • vulnerable to AZ failure, plan accordingly
    • easy to snapshot, which is stored on S3 and multi-AZ durable.
    • supports RAID configs. AWS does not recommend RAID5 & RAID6 because the parity bit writing consumes too much network bandwidth & IOPS.
      • RAID0: no redundancy, fast reads/writes, 100% capacity utilization
      • RAID1: mirrors the data, capacity is 50%, can tolerate 1 drive failure. A bit slower than RAID0 for reads/writes
      • RAID5: at least 3 drives, one drive stores the parity bit, can recover 1 drive failure. Reads are fast, writes are slow
      • RAID6: Requires at least 4 drives. 2 drives can fail. Reads are fast, writes are even slower

Compute

  • Make sure your AMIs are up-to-date
  • Horizontal scaling is preferred, risk can be spread across multiple smaller machines vs one large machine
  • Reserved instances is the only way to guarantee that resources will be available when needed

Database

  • Choose dynamodb over RDS, more fault tolerant
  • If dynamodb can't be used, choose Aurora because of the redundancy and auto recovery features
  • If aurora can't be used, choose multi-AZ RDS
  • Frequent RDS snapshots can protect against data corruption or failure, does not impact performance of multi-AZ deployment
  • regional replication in RDS is another way to provide fault tolerance, but the replication is eventually consistent

Redshift

  • does not support multi AZ deployments
  • Best HA (high availability) option is using a multi-node cluster that supports data replication and node recovery
  • single node cluster does not support data replication, you'll have to restore data from a snapshot on S3 if a drive fails.

Memcached

  • does not support replication, node failure will result in data loss
  • use multiple nodes in each shard to minimize data loss on node failure
  • launch multiple nodes across available AZs to minimize data loss on AZ failure

Redis

  • use multiple nodes in each shard and distribute nodes across multiple AZs
  • enable multi AZ on the replication group to permit automatic failover if primary node fails
  • schedule regular backups of the redis cluster

Network

  • Create subnets in available AZs, create multi-AZ presence for your VPC
  • create at least two VPN tunnels into your virtual private gateway for redundancy
  • direct connect is not HA by default, so you need to establish a secondary connection via another direct connect (ideally with another ISP) or use a VPN
  • for multi-AZ redundancy of NAT Gateways, create gateways in each AZ with routes for private subnets to use the local gateway

Deployment and Ops Management

  • Rolling: Create new AMI (can't edit AMIs) and terminate instances, new instances will come up with the new AMI
  • A/B testing: two versions of the app, behind two load balancers, Route53 routes 90% traffic to one ALB, 10% to other
  • Canary release: Release new version of the app on a server, monitor and if no errors gradually rollout to others
  • Blue/green: like A/B testing, but this time switch all at once and if you face any issues you switch back to the original version. Provides a way to have immutable infra, very easy to rollback. Three ways to achieve this:
    • Can be done with DNS in Route53 by updating the record to point to new ELB or instance
    • swap auto-scaling group behind the ELB
    • change auto-scaling group launch config to use new AMI version and terminate old instances.
    • if using Elastic Beanstalk, swap environment URL
    • we can also clone a stack in AWS OpsWorks and update the DNS

Blue-green deployments are not applicable to all apps, for instance if there's a breaking schema change that can't be rolled back then blue/green deployments are not suitable in that scenario, because you can't rollback automatically to the previous state of the database.

CI/CD

  • CI: merge changes back to main branch as freq as possible with automated testing as you go

  • Continuous delivery: automated process to release, such that you can deploy at the click of a button

  • Continuous Deployment: each change flows to production automatically once it passes all the checks

  • Should aim for small changes to reduce the risk and limit any impact.

  • Should have good test coverage

  • AWS tools for CI/CD

    • CodeCommit: git
    • CodeBuild: build code and create deployment packages
    • CodeDeploy: deploys packages on EC2, lambda, Elastic Beanstalk or ECS (or even on on-prem)
    • CodePipeline: orchestrates the above
    • CodeStar: turn-key solution that encompassess all above to provide a ready to use CI/CD pipeline

Elastic Beanstalk

  • Orchestration service to make it push-button easy to deploy web apps
  • Wide range of supported platforms, docker, php, java, nodejs etc.
  • multi envs within app (dev, qa, prod etc)
  • Elastic Beanstalk deployments run in their own self-contained environment and don't share resources.
  • easy to deploy but not good if you need control and flexibility
  • Deployment options:
    • all at once: causes downtime, rollback is manual, deploys fast
    • rolling: 1 by 1, deploys slower, no downtime, manual rollback
    • rolling with additional batch: launch new instances before taking old versions down, even slower, no downtime, manual rollback
    • immutable: a full set of new version instances in separate auto-scaling group, only cut over to new set once health check is passed. No downtime, takes longer to deploy. To rollback terminate new instances.
    • traffic splitting: percent of traffic is routed to new instances for canary testing, slow to deploy, no downtime, reroute dns and terminate new instances for rollback
    • blue/green: CNAME DNS entry changed when new version is up, leaving old version in place until deployment is verified. Slow, without downtime, to rollback just swap the URL

CloudFormation

  • IaC, JSON or YAML
  • Repeatable automatic rollbacks and deployments
  • nest common resources for reusability
  • supports custom resources through SNS or Lambda
  • stack policies: to have a mechanism to prevent a resource to be deleted, for instance you don't want anyone to delete a database from the stack. So when somebody deploys a template by mistake, the db will not be affected.
  • stack policies are added via console or CLI. Once stack is created, you can only add them through the CLI. Once applied can't be removed, but can be modified via CLI.
  • by default stack policies deny everything, DENY: update:*
  • stack: when you deploy a cloudformation template
  • change set: when you incrementally make changes and deploy, CF creates a change set that represents the change in the stack

Elastic Container Service (ECS)

  • EKS: Elastic Kubernetes Service. If you have existing K8 apps, easy to lift and shift
  • ECS: aws specific platform that supports docker containers.
  • ECS is simpler to learn and use, EKS is more feature-rich but has steep learning curve
  • ECS leverages Route53, ALB, CloudWatch etc. but EKS has those built into the platform which is a hosted K8 platform
  • ECS calls instances of containers "tasks", kind of isolated compute.
  • EKS calls them "pods", which can have shared access to each other.
  • pods are a concept with Kubernetes and not ECS.
  • ECS has two launch types:
    • EC2: you have more control, you are responsible for managing upgrading and cluster optimization
    • Fargate: control plane asks for resources and Fargate provisions them automatically, less control, managed solution

API Gateway

  • REST APIs
  • Can proxy for an AWS service, or any other HTTP API, or can run code via Lambda
  • Regionally based, private or edge optimized (via CloudFront)
  • Supports caching

Management Tools

  • AWS Config
    • allows audit, assess, evaluate configs of your AWS resources
    • very useful for config management as part of an ITIL program
    • creates baseline of various config settings and files and track changes against that baseline
    • Config rules can check resources for certain desired conditions and if violations are found they can be flagged as noncompliant.
    • example rules: Is backup enabled on RDS? Is cloudtrail enabled? Are EBS volumes encrypted? etc.
  • AWS OpsWorks:
    • managed instance of chef and puppet (two popular automation platforms)
    • provide config management to deploy code, configure instances etc.
    • has three offerings: Chef Automate, Puppet Enterprise, Stacks
    • Chef Automate and Puppet Enterprise are fully managed
    • Stacks is an AWS creation and uses embedded Chef solo client on EC2 to run Chef recipes
    • Stacks support EC2 instances and on-prem servers (for on-prem you need to install agents)
    • Stacks: collection of resources needed to support a service or app.
    • OpsWorks Stacks offers three types of scaling:
      • 24/7 for instances that remain on all the time;
      • time-based for instances that can be scheduled for a certain time of day and on certain days of the week;
      • load-based scaling which will add instances based on metrics. All this can be configured from within the OpsWorks Stack console.
    • Layers represent components of the app delivery hierarchy
    • EC2, RDS instances and ELBs are examples of layers
    • Stacks can be cloned, within the same region only
    • OpsWorks is a global service, but when you create a stack you choose a region

AWS Systems Manager

  • Centralized console and toolset for many system management tasks
  • Designed for managing large fleet of systems, tens or hundreds
  • SSM agent enables system manager features and supports all OSs
  • SSM agent installed by default on recent AWS provided AMIs
  • Manages AWS-based and on-prem systems via the agent
  • Has many services within:
    • Inventory: collect os app and instance metadata on instances
    • State manager: create states that represent certain config is applied to instances (keep track of config, version etc for instances like apache version for instance)
    • Logging: cloudwatch log agent
    • parameter store: shared secure storage for config data, connection strings, passwords etc.
    • insights dashboard: account level view of cloudtrail, config and trust advisor. useful for keeping an eye on config compliance.
    • resource groups: to organize resources through tagging, you can use this to create a dashboard for all assets for the production ERP for instance.
    • maintenance windows: scheduled patch update or run scripts
    • automation: automate routine maintenance scripts and tasks (stop dev and QA instances every Friday and start back on Monday)
    • run command: runs commands and scripts without logging in via SSH or RDP. Run a shell script on 100 different instances at the same time.
    • Patch manager: automates process of patching instances for updates.
  • Patch Manager baselines: you can mark critical updates to be applied right away, some may be optional so they won't be applied for some time, etc.
  • System Manager Documents: JSON or YAML files, stored as versions.
    • Command Document: run command state manager
    • Policy Document: used with State manager to enfore a policy for the targets
    • Automation Document: used with Automation service.

Enterprise Apps

  • WorkSpaces and Appstream are similar services but have some differences. Both good for remote seasonal workers.
    • WorkSpaces: desktop as a service, good for remote workers you get a new remote PC
    • AppStream: encapsulates apps and lets you access them via a web browser. For instance you could run MS Word on this.
  • AWS Connect: fully managed cloud-based contact center solution, can integrate with CRM systems
  • Amazon Chime: Skype
  • WorkDocs: online doc store like google drive or dropbox
  • WorkMail: fully managed email and calendar as a service
  • WorkLink: secure access to internal web apps for mobile devices
  • Alexa for Business

Machine Learning

  • SageMaker: custom ML services
  • AI services: Comprehend, Lex, Translate, Rekognition, Personalize etc.
  • Comprehend: NLP, sentiment analysis of social media posts
  • Forecast
  • Lex: understand natural speech. Lex also converts speech to text, so the input is speech.
  • Personalize
  • Polly: text to speech
  • Rekognition: image processing
  • Textract: OCR
  • Transcribe: speech to text
  • Translate: google translate

Cost Management

  • Capital Expenses (capex): money spent on long term assets
  • Operational Expenses (opex): money spent for ongoing costs running the business
  • Total cost of ownership (TCO): entire cost model of a given decision or option
  • Return of investment (ROI): amount that we expect to receive back within a certain amount of time for a given investment
  • Use tagging to track costs better
  • Most resources can have up to 50 tags
  • Resource groups: groupings of AWS assets defined by tags. Use this to create custom consoles to consolidate metrics, alarms and config. On the console you can select your resource group for those views.

Reserved instances

  • Purchase or agree to purchase EC2 instances in advance for a discount
  • Provides capacity reservation when used in a specific AZ
  • 3 types: Standard, Convertible & Scheduled
  • RIs can be shared across accounts within consolidated billing
  • RIs can be sold on the reserved instance marketplace
  • standard
    • 1-3 years
    • cheaper than convertible
    • can change AZ, instance size or networking type
    • can't change instance family, os, tenancy or payment options
    • can't benefit from price reductions
    • sellable on marketplace
  • convertible:
    • 1-3 years
    • can change AZ, instance size or networking type
    • can change instance family, os, tenancy or payment options
    • can benefit from price reductions
  • If you choose zonal RI, that RI is reserved and discount applies to that AZ only. You can change zonal to regional back and forth
  • For server bound software licenses, use dedicated hosts (physical servers dedicated to your use)
  • Dedicated hosts can't be part of an autoscaling group
  • dedicated instance: virtual machine, residing on hardware that you don't share with anybody else
  • You can't move RIs between regions.
  • Dedicated Instances are Amazon EC2 instances that run in a virtual private cloud (VPC) on hardware that's dedicated to a single customer. Dedicated Instances that belong to different AWS accounts are physically isolated at a hardware level, even if those accounts are linked to a single payer account. However, Dedicated Instances might share hardware with other instances from the same AWS account that are not Dedicated Instances.

AWS Budgets

  • allows to set predefined limits and notifications
  • can be based on cost, usage, reserved instance utilization or coverage
  • useful method to distribute cost awareness and responsibility to platform users
  • consolidated billing: enables single payer account, economies of scale by bringing together resource consumption across accounts
  • Trusted Advisor: can point out where we might be missing some opportunity for reducing costs. This is an automated check. Full benefits are available for only business or enterprise support plan. Core functionality is available for all.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment