Last week, AWS announced the general release of AWS Cost Categories. Anyone involved in managing AWS costs within your organization should ensure they understand this new feature and start using it for better cost allocation and billing management.
What are AWS cost categories?
AWS cost categories are a new way to create custom groups that transcend tags and allow you to better manage costs according to your organizational structure, for example, by application group, team, or location.
Cost categories allow you to write rules and create custom groups of billing line items, which you can then use in AWS Cost Explorer, AWS Budgets, the AWS Cost and Usage Report, etc. You can group by account, tag, service, and charge types.
How are cost categories different from tags?
At first, this “category” structure may seem similar to the tagging structure you already use in Cost Explorer, but there are a few key differences.
First, you can create logic to categorize costs from specific services to all belong to the same team. For example, you may have RDS resources belong to a category for the DBA team; Redshift belong to a FinOps category, or CodePipeline belong to a DevOps category. Categories also allow you to include resources that are not taggable, such as AWS support costs and some Reserved Instance charges.
Why should you use AWS cost categories?
The ability to create your own categorization rules is what makes this new option powerful. You can do this through the Cost Categories rule builder, JSON editor, or API. The rule builder is straightforward and has some built-in logic options such as “is, is not, contains, starts with” and “ends with”.
For organizations with many AWS accounts, categories of accounts into business units, products, applications, or production vs. non-production are helpful in allocating and evaluating costs.
Ensure costs are in control
Of course, whenever you take a closer look at your current costs, you’ll find areas that can be better optimized. Make sure you are only paying for the AWS resources you actually need, and schedule idle resources to turn off using ParkMyCloud – now supporting EKS and soon to support Redshift.
If you use AWS, it’s likely you’ll use or at least run across Amazon Redshift – so make sure you know these eight things about how AWS Redshift Pricing works.
Amazon Redshift Overview
AWS calls Redshift the “most popular and fastest” cloud data warehouse. It is fully-managed, and scalable to petabytes of data for storage and analysis. You can use Redshift to analyze your data using SQL and business intelligence tools. It features:
Integration with data lakes and other AWS services that allows you to query data and write data back to data lake in open formats
High performance – fast query performance, columnar storage, data compression, and zone maps.
Petabyte scale – “virtually unlimited” according to AWS, with scalable number and type of nodes, with limitless concurrency.
There are three node types, two current and one older:
RA3 nodes with managed storage – scale and pay for compute and managed storage independently. You choose the number of nodes based on performance requirements and pay only for the storage you used. Managed storage uses SSDs in each RA3 nodes for local storage, and Amazon S3 for longer-term storage. If the data in your node exceeds the local SSDs, data will be automatically offloaded to S3.
DC2 nodes – these compute-intensive data warehouses include local SSD storage. You choose the number of nodes based on data size and performance requirements. Data is stored locally, and as it grows, you can add more compute nodes. AWS recommends this for datasets under 1TB uncompressed, otherwise, use RA3 for the S3 offloading capability to keep costs down.
DS2 nodes – these use HDDs, andAWS recommends you use RA3 instead.
Where did the name come from? In astronomy, “redshift” refers to the lengthening of electromagnetic radiation toward longer wavelengths as an object moves away from the observer – the light equivalent of the change in an ambulance siren pitch as it passes you, collectively known as the Doppler Effect. Or, if you’re into gossip, it’s a thumb to the nose at “big red” Oracle.
AWS Redshift Pricing Structure
So, how much does Amazon Redshift cost? Like EC2 and other services, the core cost is on-demand by the hour, based on the type and number of nodes in your cluster.
Core On-Demand Pricing
RA3 – as of this writing, prices range from $3.26 per hour for an ra3.4xlarge in US East (N. Virginia) to $5.195 for the same type in Sao Paulo. Price increases linearly with size, with the ra3.16xlarge costing 4 times the ra3.4xlarge.
Data stored in managed storage is billed separately based on actual data stored in the RA3 node types, at the same rate whether your data is in SSDs or S3.
DC2 – the dc2.large currently costs $0.25 per hour in US East (N. Virginia) up to $0.40 in Sao Paulo.
Note: We’ve omitted DS2 as those are no longer recommended.
Pricing for Additional Capabilities
Amazon Redshift Spectrum Pricing – Redshift Spectrum allows you to run SQL queries directly against Amazon S3 data. You are charged for the number of bytes scanned by Spectrum, rounded up by megabyte, with a 10MB minimum per query. Compressed and columnar data will keep costs down. Current pricing is $5 per terabyte of data scanned.
Concurrency Scaling Pricing – you can accumulate one hour of concurrency scaling cluster credits every 24 hours while your main cluster is running. Past that, you will be charged the per-second on-demand rate
Redshift Managed Storage Pricing – managed storage for RA3 node types is at a fixed GB-month rate for the region you are using. It is calculated per hour based on total data present in the managed storage.
8 Things to Keep in Mind
Of course, there’s always more to know.
Free trial – for your first Redshift cluster, you can get a two month free trial of a DC2.Large node. It’s actually a trial of 750 hours per month, so if you use more than 160GB of compressed SSD storage or run multiple nodes, you will exhaust that in less than one month, at which point you’ll be charged the on-demand rate unless you spin down the cluster. This is separate from the AWS Free Tier.
Reserved Instances are available – by paying upfront, you can pay less overall – 3% to 63% depending on the payment options you choose. But should you use them?
Billed per-second – for partial hours, you will only be billed at a per-second rate. Surprisingly, this was only released in February of this year.
You can pause – you can pause and resume to suspend billing, but you will still pay for backup storage while a cluster is paused.
Redshift Spectrumpricing does not include costs for requests made against your S3 buckets – see S3 pricing for those rates.
Redshift managed storage pricingdoes not include backup storage due to snapshots, and once the cluster is terminated, you will still be charged for your backups. Don’t let these get orphaned!
Data transfer– there is no charge for data transferred between Amazon Redshift and Amazon S3 within the same region for backup, restore, load, and unload operations – but for all other data transfers in and out, you will be billed at standard data transfer rates.
RA3 is not available in all regions
Keep Your AWS Redshift Costs In Control
There are a few things you can do to optimize your AWS Redshift costs:
Use Reserved Instances where you have predictable needs, and where the savings over on-demand is high enough
Delete orphaned snapshots– like all backups, ensure that you are managing your snapshots and deleting when clusters are deleted
Schedule on/off times – for Redshift clusters used for development, testing, staging, and other purposes not needed 24×7, make sure you schedule them to turn off when not needed – now possible with the announcement from last month that Redshift clusters can now be paused. Automated scheduling coming soon in ParkMyCloud!
Anytime you provision infrastructure from Amazon Web Services (AWS), you will need to choose which of the AWS Regions and Availability Zones it will live in. Here are 5 things you need to know about these geographic groupings, including tips on how to choose, and things to watch out for.
1. What are AWS Regions and How Many are There?
AWS Regions are the broadest geographic category that define the physical locations of AWS data centers. Currently, there are 22 regions dispersed worldwide across North America, South America, Europe, China, Africa, Asia Pacific and the Middle East. All Regions are isolated and independent of one another.
Every region consists of multiple, separate Availability Zones within a geographic area. AWS offers Regions with a multiple AZ design – unlike other cloud providers who see a region as one single data center.
AWS has a larger footprint around the globe than all the other cloud providers, and to support their customers and ensure they maintain this global footprint, AWS is constantly opening new Regions.
Here’s a look at the different regions and their AWS code.
US East (Ohio)
US East (N. Virginia)
US West (N. California)
US West (Oregon)
US GovCloud West
US GovCloud East
Asia Pacific (Hong Kong)
Asia Pacific (Mumbai)
Asia Pacific (Seoul)
Asia Pacific (Singapore)
Asia Pacific (Sydney)
Asia Pacific (Tokyo)
Middle East (Bahrain)
South America (São Paulo)
**Note: AWS manages US GovCloud, AWS China, and the general AWS as distinct “partitions”. An account must be set up within the partition to get access to any of the regions in that partition.**
2. What are AWS Availability Zones and How Many are There?
An Availability Zone (AZ) consists of one or more data centers at a location within an AWS Region. Each AZ has independent cooling, power, and physical security. Additionally, they are connected through redundant, ultra-low-latency networks.
In AZ’s, customers are able to operate production applications and databases that are more fault tolerant, scalable, and highly available than you would see from a single data center.
Every AZ in an AWS Region is interconnected with high-bandwidth, low-latency networking, fully redundant, metro fiber in order to provide high-throughput, low-latency networking between AZ’s. All AZ’s are physically separated by a significant distance from any other AZ, although all are within 60 miles of each other.
Around the world, there are currently 69 Availability Zones. Here’s a breakdown of each Availability Zones you can find within a Region.
# of Availability Zones
US East (Ohio)
US East (N. Virginia)
US West (N. California)
US West (Oregon)
US GovCloud West
US GovCloud East
Asia Pacific (Hong Kong)
Asia Pacific (Mumbai)
Asia Pacific (Seoul)
Asia Pacific (Singapore)
Asia Pacific (Sydney)
Asia Pacific (Tokyo)
Middle East (Bahrain)
South America (São Paulo)
There is also an option available called AWS Local Zones. This allows deployment of latency-sensitive portions of applications close to large populations where no AWS region currently exists. The first one is Los Angeles, which belongs to the Oregon region (and not the California region).
3. How to Choose a Region/AZ
So that’s what they are – now how do you choose a region and availability zone for
Distance – choose regions close to you and your customers to keep latency low
Service availability – as we’ll discuss more below, there are some regions that offer more services than others, and new services will tend to be introduced in these regions first.
Cost– always check the AWS pricing calculator to compare the cost between regions. N. Virginia is usually the least expensive among others. Sao Paulo is typically the most expensive.
Compliance – GDPR, government contracting, and other regulated industries may require a specific region or multiple regions
4. What Sorts of Functions are Defined by Region and Availability Zone?
Some services, like AWS IAM, do not support Regions. Therefore, the endpoints for those services do not include a Region. Other services, such as Amazon EC2, support Regions but, you are able to specify an endpoint that does not include a Region. Additionally, Amazon Simple Storage Service (Amazon S3), supports cross-Region replication.
AWS Regions introduced before March 20, 2019 are enabled by default. You can begin working in these Regions immediately. Regions introduced after March 20, 2019 are disabled by default – you must enable these Regions before you can use them. Administrators for an account can enable and disable Regions and use a policy condition that controls who can have access to AWS services in a particular AWS Region.
There are some less popular services such as Alexa for Business, Amazon Augmented AI (A2I), Amazon Fraud Detector, and Amazon Mobile Analytics are only available in the US East (N. Virginia) Region.
Region Differences Across Major Services
Amazon Simple Storage Service (S3) is storage for the internet. You can use Amazon S3 to store and retrieve any amount of data at any time, from anywhere on the web.
You specify an AWS Region when you create your Amazon S3 bucket. For S3 Standard, S3 Standard-IA, and S3 Glacier storage classes, your objects are automatically stored across multiple devices ranging on a minimum of three Availability Zones, each separated across an AWS Region. Objects stored in the S3 One Zone-IA storage class are stored redundantly within a single Availability Zone in the AWS Region you select.
S3 operates in a minimum of three AZs, each separated by miles to protect against local events like fires, floods, etc. S3 is available in all Regions in North America, South America, Europe, Africa, China, Asia Pacific and the Middle East.
Amazon Elastic Compute Cloud
Amazon Elastic Compute Cloud (EC2) provides resizable, scalable computing capacity in the cloud. Each Amazon EC2 Region is designed to be isolated from the other Amazon EC2 Regions. This achieves the greatest possible fault tolerance and stability.
When you view your resources, you see only the resources that are tied to the Region that you specified. Why does this happen? Because Regions are isolated from each other, and resources are not automatically replicated across Regions.
When you launch an EC2 instance, you must select an AMI that’s in the same Region. If the AMI is in another Region, you can copy the AMI to the Region you’re using. When you launch an instance, you can select an Availability Zone or let Amazon choose one for you.
EC2 is available in all Regions in North America, South America, Europe, Africa, China, Asia Pacific and the Middle East.
AWS Lambda runs your code in response to triggers and automatically manages the compute resources for you. Lambda maintains compute capacity across multiple AZ’s in each Region in order to help protect code against individual machine or data center facility failures.
AWS Lambda is available in all Regions in North America, South America, Europe, Africa, China, Asia Pacific and the Middle East. The only region Lambda is not available in is Osaka, which is a local region. This type of region is new and is made up of an isolated fault-tolerant infrastructure design located in a single data center.
Amazon Simple Notification Service
Amazon SNS is a highly available, durable, secure, fully managed messaging service that allows you to decouple distributed systems, microservices, and serverless applications. SNS uses cross availability zone message storage to provide high message longevity.
Amazon SNS is available in all Regions in North America, South America, Europe, Africa, China, Asia Pacific and the Middle East.
Amazon Elastic Block Store (EBS) is AWS’s block-level, persistent local storage solution for Amazon EC2 that allows you to minimize data loss and recovery time while being able to regularly back up your data and log files across different geographic regions.
EBS volumes are replicated within an Availability Zone (AZ) and can easily scale to petabytes of data. Each volume is designed to protect against failures by replicating within the Availability Zone (AZ), offering 99.999% availability and an annual failure rate (AFR) of between 0.1%-0.2%. You can also quickly restore new volumes to launch applications in new regions.
EBS Snapshots can be used to quickly restore new volumes across a region’s Availability Zones, enabling rapid scale.
EBS is available in all Regions in North America, South America, Europe, Africa, China, Asia Pacific and the Middle East.
5. Transferring Data Between Regions Can Matter Too
Transferring data between AWS services within a region costs differently depending on whether you’re transferring data within or across AZs.
Data transfers are free if you are within the same region, same availability zone, and use a private IP address. Data transfers within the same region, but in different availability zones, have a cost associated with them.
So, to summarize, AWS Regions are separate geographic areas and within these regions are isolated locations that are known as Availability Zones (AZ). It’s important to pay attention to the services offered in each Region and AZ so you can make sure you are getting the most optimal service in your area.
AWS offers a range of EC2 instance types optimized for various purposes. It’s great that they provide so much variety, but of course, it means one more thing that you have to learn. It’s worth taking the time to do so, as ⅔ of IaaS spend goes toward compute – that’s a lot of EC2.
Check out a brief breakdown in this video, which also compares EC2 purchasing options. Check it out here:
Or, read on for a look into each of the AWS instance types. Remember that within each type, you’ll still need to choose the AWS instance sizes that suit your specific needs. Additionally, older generations within each instance types are available for purchase – for example, c5 is the latest “c” instance, but c4 and c3 are still available – but as the newer types tend to perform better at a cheaper price, you’ll only want to use the older types if you have an AMI or other dependency. The differences matter for some users… but you probably already know who you are.
Note: a version of this blog was originally published in July 2018. It has been rewritten and updated for 2020. New EC2 instance types since our last writeup include A1, T3, z1d, high memory, R5, G4, and F1.
Quick EC2 Instance Info
This chart shows a quick summary of what we’ll cover. We’re including a brief description and mnemonic for each (hopefully helpful if you’re studying for an AWS certification!)
If you’ve taken a look at AWS training materials, you may have seen a couple of overall acronyms to remember all of these – perhaps Dr McGiFT Px or FIGHT Dr McPX. Whether these acronyms are useful at all is perhaps a point of discussion, but to ensure that all the instance types above are in your list, we suggest:
Fight Czar MXPD
Fright Camp DXZ
March Gift PZXD
(and don’t forget high memory and Inf!)
These general purpose AWS EC2 instance types are a good place to start, particularly if you’re not sure what type to use. There are three general purpose types.
t instance type
The t3 family is a burstable instance type. If you have an application that needs to run with some basic CPU and memory usage, you can choose t3. It also works well if you have an application that gets used sometimes but not others. When the resource is idle, you’ll generate CPU credit, which you’ll utilize when the resource is used. It’s useful for things that come and go a lot, such as websites or development environments, and while generally inexpensive, make sure you understand how the CPU credits work before deploying these. There’s a little bit of math and they may not be as cheap as they look at first glance.
Make sure you also understand the difference between t3 and the older t2 – t3 are in “unlimited mode” by default, so instead of throttling down to baseline CPU when your instance runs out of credits, you pay for overages.
For each of the EC2 types we cover here, we’ll also add a mnemonic to help you remember the purpose of each instance type.
Mnemonic: t is for tiny or turbo.
m instance type
The m5 instance type is similar, but for more consistent workloads. It has a nice balance of CPU, memory, and disk. It’s not hard to see why almost half of EC2 workloads are on “m” instances. In addition to m5, you also have the option of m6g, which are powered by Arm-based AWS Graviton2 processors, making them more cost-efficient. There’s also m5a, m5n, and m4 – most of which are safe to ignore unless you have a specific use case for one of the other processors besides m5’s Intel Xeon Platinum 8175 processors. If you aren’t sure what to choose, m5 is the most versatile of all the Amazon instance types.
Mnemonic: m is for main choice or happy medium.
a1 instance type
The a1 instance type was announced in late 2018 and can be a less expensive option than other EC2. They are suited for scale-out workloads such as web servers, containerized microservices, caching fleets, distributed data stores, and development environments. The instances are powered by Arm processors and suited for Arm-based workloads.
Mnemonic: a is for Arm processor
c instance type
The c5 instance type has a high ratio of compute/CPU versus memory. If you have a compute-intensive application – maybe scientific modelling, intensive machine learning, or multiplayer gaming – these instances are a good choice. There is also the c5d option, which is SSD-backed. See also the C5n which have up to 100 Gbps network bandwidth and increased memory compared to equivalent c5 instances. The c4 family is also still available.
Mnemonic: c is for compute (at least that one’s easy!)
r instance family
The r instance family is memory-optimized, which you might use for in-memory databases, real-time processing of unstructured big data, or Hadoop/Spark clusters. You can think of it as a kind of midpoint between the m5 and the x1e. In addition to r5, there are r5a which deliver lower cost per GiB memory and r5n which have higher bandwidth for applications that need improved network throughput and packet rate performance.
Mnemonic: r is for RAM.
x1 instance family
The x1 family has a much higher ratio of memory, so this is a good choice if you have a full in-memory application or a big data processing engine like Apache Spark or Presto. X1e are optimized for high-performance databases, in-memory databases, and other memory intensive enterprise applications.
Mnemonic: x is for xtreme, as in “xtreme RAM” seems to be generally accepted, but we think this is a bit weak. If you have any suggestions, comment below.
High Memory instance family
We’re not sure why these didn’t get an alphabet soup name like the rest of the AWS instances, but at least it’s easy to remember and understand. As you might guess, high memory instances run large in-memory databases, including production deployments of SAP HANA.
Mnemonic: we’ll leave this one up to you.
z1d instance family
The z1d instances combine high compute capacity with a high memory footprint. They have a sustained core frequency of up to 4.0 GHz, the fastest of AWS’s offerings. These are best for electronic design automation (EDA) and some relational database workloads with high per-core licensing costs.
Mnemonic: z is for zippy
p instance type
If you need GPUs on your instances, p3 instances are a good choice. They are useful for video editing, and AWS also lists use cases of “computational fluid dynamics, computational finance, seismic analysis, speech recognition, autonomous vehicles” – so it’s fairly specialized. p2 instances are also available.
Mnemonic: p is for pictures (graphics).
Inf1 instance type
The Inf1 instances are a specialized EC2 type for machine learning inference applications, such as recommendation engines, forecasting, image and video analysis, advanced text analytics, document analysis, voice, conversational agents, translation, transcription, and fraud detection.
Mnemonic: inf is for inference
g instance type
The g instance type uses Graphics Processing Units (GPUs) to accelerate graphics-intensive workloads, and also designed to accelerate machine learning inference. This could include adding metadata to an image, automated speech recognition, and language translation, as well as graphics workstations, video transcoding, and game streaming in the cloud.
g4 is the latest family, and g3 are available as well.
Mnemonic: g is for graphics or GPU
F1 instance type
f1 instances offer customizable hardware acceleration with field programmable gate arrays (FPGAs) – hence the “f”. Applications could include genomics research, financial analysis, and real-time video processing.
Mnemonic: f is for FPGA
i3 instance type
The i3 instance type is similar to h1, but it is SSD backed, so if you need an NVMe drive, choose this type. Use it for NoSQL databases, in-memory databases, Elasticsearch, and more. The i3en option has higher network bandwidth with Elastic Network Adapter (ENA)-based enhanced networking.
Mnemonic: i is for IOPS.
d2 instance type
d2 instances have an even higher ratio of disk to CPU and memory, which makes them a good fit for Massively Parallel Processing (MPP), MapReduce and Hadoop distributed computing, and similar applications.
Mnemonic: d is for dense.
h1 instance type
The h1 type is HDD backed, with a balance of compute and memory. You might use it for distributed file systems, network file systems, or data processing applications.
Mnemonic: h is for HDD.
What EC2 instance types should you use?
As AWS has continued to add options to EC2, there are now EC2 instance types for almost any application. If you have comparison questions around pricing, run them through the AWS monthly calculator. And if you don’t know, then generally starting with t3 or m5 is the way to go.
AWS CPU credits are unique to T-series instances – and they can be a bit tricky to figure out. Whether you’re using the AWS free tier or just trying to use the smallest EC2 compute instance you can, you’ll need to keep track of these credits. These credits are both generated and used by the T2 and T3 instance families to decide how much CPU power you can actually use on those EC2 instances. This can be confusing if you aren’t expecting your virtual machine to have it’s CPU power throttled, or are wondering why the cost is much higher than you thought it would be.
AWS first released a “burstable” instance type in the form of the t1.micro instance size in 2010, which was four years after the first EC2 instance size was released (m1.small in 2006, for you historians). Up until 2010, new instance sizes had always been bigger than the m1.small size, but there was demand for a VM size that could accommodate low-throughput or inconsistent workloads.
The t1.micro was the only burstable instance size for another four years, until the t2.medium was released in 2014. Soon, there was a whole range of t2 instances to cover the use case of servers that were low-powered while idle, but could have lots of potential compute resources available for the couple minutes each hour they were needed. In 2018, AWS introduced the t3 family that uses more modern CPUs and the AWS Nitro system for virtualization.
AWS CPU Credits 101
The key reason why T-series instances have a lower list price than corresponding M-series instances (in standard mode, more on that later) is the CPU credits that are tracked and used on each resource. The basic premise is that an idle instance earns credits, while a busy instance spends those credits. A “credit” corresponds to 1 minute’s worth of full 100% CPU usage, but this can be broken down in different ways if the usage is less than 100%. For instance, 10% of CPU usage for 10 minutes also uses 1 credit. Each T-series machine size not only has a number of CPUs available, but also earns credits at different rates.
Here’s where the math starts getting a little tricky. A t2.micro instance earns 6 credits per hour with 1 available CPU. If you run that instance at 10% utilization for a full hour, it’ll spend 6 credits per hour (or 1 credit every 10 minutes). This means that any time spent under 10% utilization is a net increase in CPU credits, while any time spent above 10% utilization is a net decrease in CPU credits. A t3.large instance has 2 CPUs and earns 36 credits per hour, which means the balancing point where the net credit use is zero will be at 30% utilization per CPU.
So what happens when you run out of credits or never use your credits?
Standard Mode vs. Unlimited Mode
One of the differences between the t2 family and the t3 family is the default way each handles running out of credits. The t2 family defaults to Standard Mode, which means that once the instance has run out of credits to use, the CPU is throttled to the baseline value we calculated above (so 10% for t2.micro) and will continue maxing out at that value until credits have built back up. In practice, this means that your process or application that has burst up to use a lot more CPU than normal will soon be slow and unusable if the load remains high.
In 2017, AWS introduced Unlimited Mode as an option for t2 instances – and later, in 2018, as the default for t3 instances when they were introduced. Unlimited mode means that instead of throttling down to the baseline CPU when your instance runs out of credits, you can continue to run at a high CPU load and just pay for the overages. This price is 5¢ per CPU hour for Linux and 9.6¢ per CPU hour for Windows. In practice, this means that a t2.micro that has run out of credits and is running at 35% CPU utilization for a full 24 hours would cost an additional 30¢ that day on top of the normal 27.84¢ for 24hr usage, meaning the price is more than doubled.
Using T-series Instead of M-series
These overage charges for Unlimited Mode of t2 and t3 instances means that while the list price of the instance is much cheaper than corresponding m4 and m5 instances, you need to figure out if the utilization pattern of your workload makes sense for a burstable instance family. For example, an m5.large in us-east-1 costs 9.6¢/hr and a t3.large with similar specs costs 8.32¢/hr with a 30% CPU baseline. If your t3.large server is going to be running higher than 55.6% CPU for the hour on a consistent basis, then the price of the m5.large is actually lower.
When to Stop T-series and When to Let Them Run
One perk of using the t2 instances in Standard mode is that each time you start the server, you receive 30 launch credits that allow a high level of CPU usage when you first start the instance from a stopped state. These launch credits are tracked separately from accrued credits and are used first, so servers that only need to run short-lived processes when first starting can take advantage of this fact. The downside of stopping t2 servers is that accrued credits are lost when you stop the instance.
On the other hand, t3 servers persist earned credits for 7 days after stopping the instance, but don’t earn launch credits when they are first started. This is useful to know for longer-running processes that don’t have huge spikes, as they can build up credits but you don’t need to worry about losing the credits if you stop the server.
At ParkMyCloud, we specialize in scheduling servers and databases to turn off on a schedule, which is perfect for non-production servers. We find that lots of users have t2 and t3 instances for these dev and test workloads, but want to know what happens to credits if you park those servers overnight. As we discussed, AWS CPU credits go away in T2 standard mode (but with additional launch credits) but persist in T3 Unlimited mode. Knowing this, you can pick the right instance size for the workload you’re running and confidently save money using ParkMyCloud.
Best for non-production instances that have a quick burst of usage when starting = T2 instance with ParkMyCloud parking schedule
Best for non-production instances with unpredictable, but sporadic spikes = T3 instance with ParkMyCloud parking schedule
Try it for free to see how we can make the cost of your t2 and t3 servers even lower.
When it comes to AWS training resources, there’s no shortage of information out there. Considering the wide range of videos, tutorials, blogs, and more, it’s hard knowing where to look or how to begin. Finding the best resource depends on your learning style, your needs for AWS, and getting the most updated information available. Whether you’re just getting started in AWS or consider yourself an expert, there’s an abundance of resources for every learning level. With this in mind, we came up with our 7 favorite AWS training resources, sure to give you the tools you need to learn AWS:
1. AWS Self-Paced Labs
What better way to learn that at your own pace? AWS self-paced labs give you hands-on learning in a live AWS environment, with AWS cloud services, and actual scenarios you would encounter in the cloud. There are two different ways to learn with these labs. You can either take an individual lab or follow a learning quest. Individual labs are intended to help users get familiar with an AWS service as quickly as 15 minutes. Learning quests guide you through a series of labs so you can master any AWS scenario at your own pace. Once completed, you will earn a badge that you can boast on your resume, LinkedIn, website, etc.
Sometimes the best way to learn something is by jumping right in. With the AWS Free Tier, you can try AWS services for free. This is a great way to test out AWS for your business, or for the developers out there, to try services like AWS CodePipeLine, AWS Data Pipeline, and more. While you are still getting a hands-on opportunity to learn a number of AWS services, the only downside is that there are certain usage limits. You can track your usage with a billing alarm to avoid unwanted charges, or you can try ParkMyCloud and park your instances when they’re not in use so you get the most out of your free tier experience. In fact, ParkMyCloud started its journey by using AWS’s free tier!
3. AWS Documentation and Whitepapers
AWS Documentation is like a virtual encyclopedia of tools, terms, training, and everything AWS. You’ll find case studies, tutorials, cloud computing basics, and so much more. This resource is a one-stop-shop for all of your AWS documentation needs, whether you’re a beginner or advanced user. No matter where you are in your AWS training journey, AWS documentation is always a useful reference and certainly deserves a spot in your bookmarks.
Additionally, you’ll findwhitepapers that give users access to technical AWS content that is written by AWS and individuals from the AWS community, to help further your knowledge of their cloud. These whitepapers include things from technical guides, reference material, and architecture diagrams.
So far, we’ve gone straight to the source for 3 out of 7 of our favorite AWS training resources. Amazon really does a great job of providing hands-on training, tutorials, and documentation for users with a range of experience. However, YouTube opens up a whole new world of video training that includes contributions from not only Amazon, but other great resources as well. Besides the obvious Amazon Web Services channel, there are also popular and highly rated videos by Edureka, Simplilearn, Eli the Computer Guy, and more.
As cloud technology usage continues to expand and evolve, blogs are a great way to stay up to speed with AWS and the world of cloud computing. Of course, in addition to aws labs, a free-trial, extensive documentation, and their own YouTube channel, AWS also has their own blog. Since AWS actually has a number of blogs that vary by region and technology, we recommend that you start by following Jeff Barr – Chief Evangelist at Amazon Web Services, and primary contributor. Edureka was mentioned in our recommended YouTube channels, they also have a blog that covers plenty of AWS topics. The CloudThat blog is an excellent resource for AWS and all things cloud, and was co-founded by Bhaves Goswami – a former member of the AWS product development team. Additionally, AWS Insider is a great source for all things AWS. Here you’ll find blogs, webcasts, how-to, tips, tricks, news articles and even more hands-on guidance for working with AWS. If you prefer newsletters straight to your inbox, check out Last Week in AWS and Inside Cloud.
6. Online Learning Platforms
As public cloud computing continues to grow – and AWS continues to dominate the market – people have become increasingly interested in this CSP and what it has to offer. In the last 8-10 years, two massive learning platforms were developed, Coursera and Udemy. These platforms offer online AWS courses, specializations, training, and degrees. The abundance of courses that these platforms provide can help you learn all things AWS and give you a wide array of resources to help you train for different AWS certifications and degrees.
GitHub is a developer platform where users work together to review and host code, build software and manage projects. This platform has access to a number of materials that can help further your AWS training. In fact, here’s a great list of AWS training resources that can help you prepare for an Amazon Cloud certification. The great thing about this site is the collaboration among the users. The large number of people in this community brings together people from all different backgrounds so they are able to provide knowledge about their own specialties and experiences. With access to everything from ebooks, video courses, free lectures, and sample tests, posts like these can help you get on the right certification track.
There’s plenty of information out there when it comes to AWS training resources. We picked our 7 favorite resources for their reliability, quality, and range of information. Whether you’re new to AWS or consider yourself an expert, these resources are sure to help you find what you’re looking for.