AWS Certified Solutions Architect Professional – Study Guide – Domain 2.0 Costing

2.1 Demonstrate ability to make architectural decisions that minimize and optimize infrastructure cost

• Costs can be controlled by using Reserved Instances if the required compute resource is fairly static and predictable – any excess capacity may be resold on the Marketplace. Reserved Instances have three payment models:-
  • All up front (up to 75% discount)
  • Partial upfront (middle discount)
  • No upfront (no discount, but still cheaper than On Demand)
  • Contract length is 1 or 3 years
• Reserved Instances can be cost effective when the steady state load is known – purchasing RIs to service this requirement and then using On Demand or Spot for bursting can be an effective cost strategy
• Reserved instances can be modified
  • Can be moved to another AZ
  • Change the instance type within the same family
  • Each instance size has a normalisation factor, which is a unitary value from 0.5 (micro) to 80 (10xlarge)

• Spot instances can provide ad hoc compute power but are transitory and can be removed without notice if the spot price goes above your limit
• On Demand instances run on a “pay as you go” model
• Legacy apps that have burstable compute requirements are more efficiently run on instances with burstable CPU credits (T2 instances). Useful for legacy applications that do not support auto scaling
• Instances use CPU credit balance which expires after 24 hours on a rolling basis. When not using full CPU, credits can accrue and be used to periodically burst
• Instance types provide optimised instances for different types of workloads and may represent the best cost vs performance question when designing a deployment. Types include:-
  • T2 – Burstable Performance Instances – useful for general purpose workloads where CPU usage may need to spike on occasion. Balanced compute/network/storage instance. Lowest cost. Use cases – test/dev, small workloads, code repos, micro instances
  • M4 – General Purpose – Xeon Haswell CPU, balanced compute/networking/storage, EBS optimised by default and has enhanced networking option. Use cases – Small and mid-size databases, data processing tasks that require additional memory, caching fleets, and for running back end servers for SAP, Microsoft SharePoint, cluster computing, and other enterprise applications
  • M3 – Largely as above, but with Ivy Bridge generation CPUs, so one generation back from M4. Use cases – Small and mid-size databases, data processing tasks that require additional memory, caching fleets, and for running backend servers for SAP, Microsoft SharePoint, cluster computing, and other enterprise applications
  • C4 – Compute Optimised – EC2 specific Haswell CPU, EBS optimised by default, support for enhanced networking and clustering . Use cases – High performance front-end fleets, web-servers, batch processing, distributed analytics, high performance science and engineering applications, ad serving, MMO gaming, and video-encoding.
  • C3 – as above, but with Ivy Bridge generation CPUs, lowest price point per GB of RAM, SSD storage and enhanced networking support. Use cases – memory-optimized instances for high performance databases, distributed memory caches, in-memory analytics, genome assembly and analysis, larger deployments of SAP, Microsoft SharePoint, and other enterprise applications.
  • G2 – GPU Optimised – for GPU and enhanced graphics applications. Sandy Bridge CPUs, NVIDIA GPU with 4GB RAM, designed to support up to eight real-time HD video streams (720p@30fps) or up to four real-time full HD video streams (1080p@30fps),  high-quality interactive streaming experiences. Use cases – 3D application streaming, machine learning, video encoding, and other server-side graphics or GPU compute workloads.
  • I2 – High I/O Instances – Ivy Bridge CPUs, SSD Storage with TRIM support, support for enhanced networking, high random I/O performance. Use cases – NoSQL databases like Cassandra and MongoDB, scale out transactional databases, data warehousing, Hadoop, and cluster file systems.
  • D2 – Dense Storage Instances – Haswell CPUs, HDD storage, consistent high performance at launch time, high disk throughput, support for enhanced networking. Lowest price per disk throughput performance on Amazon EC2. Up to 48 TB of HDD-based local storage. Use cases – Massively Parallel Processing (MPP) data warehousing, MapReduce and Hadoop distributed computing, distributed file systems, network file systems, log or data-processing applications

• EBS volume types are:-
  • General Purpose SSD (3 IOPS per GB with burstable ability, 1 GB – 16 TB) – “Better”
  • Provisioned IOPS SSD (up to 20,000 IOPS per volume, 4 GB – 16 TB) – “Best”
  • Magnetic (100 IOPS, burstable to hundreds, 500 GB – 16 TB) – “Good”

2.2 Apply the appropriate AWS account and billing set-up options based on scenario

• How do you need to handle account management and billing?
• Consolidated billing provides a way for a “master” account called the Paying Account to be responsible for a number of other AWS account’s bills (Linked Accounts)
• There is a soft limit of 20 linked accounts but this can be upped by request
• Advantages of consolidated billing
  • Single bill
  • Easy to track usage and payments
  • Volume pricing discounts across all your accounts combined
  • Reserved Instances not being used can be used to make On Demand instances cheaper. AWS will always apply the cheapest price.
• You may have acquired a company that already use AWS, you can join them together for billing
• You may also want to use different accounts for security separation
• You can use cross account access to provide permissions to resources in other accounts
  • If you need a custom policy (say to provide read/write access to a specific S3 bucket), then create this first
  • Create a role with cross account access (role type) in the primary account IAM
  • Apply the policy to that role and note the ARN
  • Grant access to the role in the secondary account
  • Switch to the role
• Configure MFA on your main billing root account, use strong passwords
• Resources should not be deployed in the paying account, this should only really be used for admin purposes
• Billing alerts can be enabled per account but when alerting is enabled on the paying account then all linked accounts are included
• CloudTrail is enabled per region and works per AWS account
• CloudTrail logs can be consolidated into an S3 bucket
  • Enable CloudTrail in the paying account
  • Create a bucket policy that allows cross account access
  • Enable CloudTrail in the other accounts and use the S3 bucket
• Budgets feature can be used to set a budget for the AWS account(s) and to send alerts when the cost goes over or close to the allocated budget by a certain percentage
• Budgets works in conjunction with CloudWatch and SNS to send alerts when costs reach a pre-set level
• Budgets can be set at a granular level (by EC2, S3, etc.) or can be set as an aggregate value across all accounts and all resources
• Notify by actual or forecasted costs
• Budget creation then provides a dashboard of total amount spent versus budget amount
• You can go over budget, these are not caps as such, but alert limits
• Redshift uses on demand and reserved instances
• EMR uses on demand and spot instances (RI discounts can be leveraged by starting EMR OD  instances in the same AZ and not having RI in use. AWS will apply the discount rates)

2.3 Ability to compare and contrast the cost implications of different architectures

• Remember that different instance types exist so that appropriate workloads can be placed on instance types that provide the best performance at the best price point, so a G2 instance would be used for GPU workloads, for example
• Unused Reserved Instances can be used to offset the cost of On Demand Instances
• Linking several accounts can provide additional discounts for services such as S3, which is charged per GB
• Use tags to provide granular billing per service. Tags work across multiple accounts that are linked using consolidated billing.
• Resource groups are created using tags and values and show a view of all resources used grouped by tag, including costs.
• If you need to make S3 content available to a single additional region, consider cross region replication rather than CloudFront. CRR is cheaper and less complex.
• Can use bi-directional cross region replication so Site A can replicate a bucket to Site B and vice versa for global replication. Versioning provides the ability to use “Recycle Bin” type functionality by allowing two writes to the same object concurrently so nothing is lost, two versions of the file are created
• Can replicate across buckets in different accounts, but IAM must allow the source bucket to write to the destination bucket. Then specify the IAM role you created with the creation policy when configuring CRR. PUTs and DELETEs are both replicated
• Use different Edge Price Class Locations to save on cost. By default, content is replicated to all regions. US and EU only is cheaper but at the cost of higher potential latency to users in other regions
• DNS queries for alias records are free of charge, CNAMEs are not