Learn how Palo Alto Networks is Transforming Platform Engineering with AI Agents. Register here

Attend a Live Product Tour to see Sedai in action.

Register now
More
Close
AWS

t3.medium

EC2 Instance

Burstable performance instance with 2 vCPUs and 4 GiB memory. Balanced resources for applications with variable CPU usage patterns.

Coming Soon...

icon
Pricing of
t3.medium

N/A

On Demand

N/A

Spot

N/A

1 Yr Reserved

N/A

3 Yr Reserved

Pricing Model
Price (USD)
% Discount vs On Demand
sedai

Let us help you choose the right instance

Schedule a meeting
icon
Spot Pricing Details for
t3.medium

Here's the latest prices for this instance across this region:

Availability Zone Current Spot Price (USD)
Frequency of Interruptions: n/a

Frequency of interruption represents the rate at which Spot has reclaimed capacity during the trailing month. They are in ranges of < 5%, 5-10%, 10-15%, 15-20% and >20%.

Last Updated On: December 17, 2024
icon
Compute features of
t3.medium
FeatureSpecification
icon
Storage features of
t3.medium
FeatureSpecification
icon
Networking features of
t3.medium
FeatureSpecification
icon
Operating Systems Supported by
t3.medium
Operating SystemSupported
icon
Security features of
t3.medium
FeatureSupported
icon
General Information about
t3.medium
FeatureSpecification
icon
Benchmark Test Results for
t3.medium
CPU Encryption Speed Benchmarks

Cloud Mercato tested CPU performance using a range of encryption speed tests:

Encryption Algorithm Speed (1024 Block Size, 3 threads)
AES-128 CBC 131.7MB
AES-256 CBC 95.1MB
MD5 894.1MB
SHA256 384.4MB
SHA512 493.4MB
I/O Performance

Cloud Mercato's tested the I/O performance of this instance using a 100GB General Purpose SSD. Below are the results:

Read Write
Max 3099 3098
Average 3052 3050
Deviation 19.49 20.01
Min 3032 3030

I/O rate testing is conducted with local and block storages attached to the instance. Cloud Mercato uses the well-known open-source tool FIO. To express IOPS the following parametersare used: 4K block, random access, no filesystem (except for write access with root volume and avoidance of cache and buffer.

icon
Community Insights for
t3.medium
AI-summarized insights
filter icon
Filter by:
All

the T series is more suitable for non-performance-verified test environments

19-03-2025
benchmarking

Amazon EC2 T3 instances are the next generation burstable general-purpose instance type that provide a baseline level of CPU performance with the ability to burst CPU usage at any time for as long as required.

28-10-2024
benchmarking

the T series is more suitable for non-performance-verified test environments

19-03-2025
benchmarking

I was able to replicate the issue and got the same error message. As a workaround, I performed the upgrade in 2-steps. First, I upgraded the instance class to t3.medium and then performed the upgrade for engine version to 15.5.

19-03-2024

I was able to replicate the issue and got the same error message. As a workaround, I performed the upgrade in 2-steps. First, I upgraded the instance class to t3.medium and then performed the upgrade for engine version to 15.5.

19-03-2024

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.

ParkMyCloud
25-02-2020
memory_usage

I ran the popular Geekbench 5 benchmark against t3.medium, t3a.medium and t4g.medium Results are below (higher score is better).

2023-02-21 00:00:00
benchmarking

We ran the tests for T3.medium vs T3.small vs T4g.medium vs T4g.small AWS RDS PostgreSQL instances and found out that all of them were very similar when it came to the speed of write/read operations when you're performing an operation that is supposed to take a short time ~ 1-5 seconds. However, where the .medium instances (both T3 and T4) really stood out was the creation of indexes on a large table and text search through a large table. In that case both T3 and T4 .medium instances were about 2x faster than the .small instances. T3 was a bit better in our tests (like 5-10%). So I'd say go with T3 and choose the RAM size depending on the largest table in your DB.

2022-02-04 00:00:00
memory_usage, benchmarking

General purpose workloads with moderate CPU, memory, and network utilization, including small and mid-size virtual desktops, databases, and business-critical apps

2025-10-03 00:00:00
memory_usage

T3 instances accumulate credits when they perform below their baseline levels.

2025-10-03 00:00:00
benchmarking

T3 instances also work with the AWS Nitro System.

2025-10-03 00:00:00
benchmarking

T3 instances use Intel Xeon Platinum 800 series processors from the first or second generation.

2025-10-03 00:00:00
benchmarking

T3 instances boost CPU performance when demand spikes; full CPU core power for one minute in Standard Mode and for as long as your workload requires in Unlimited Mode.

2025-10-03 00:00:00
benchmarking

AWS re:Invent 2020: Reduce cost with Amazon EC2’s next-generation T4g and T3 instance types

2021-05-02 00:00:00
cost_savings

I think the discrepancies can be attributed to the choice of the t-style instances. They are generally over committed.

2023-09-10 00:00:00
benchmarking

Aren\'t \'t\' instances burst instances? They need to be under constant load for a long time before their burst credits for CPU, memory, network and EBS run out, after which they fall back on their baseline performance.

2023-09-10 00:00:00
memory_usage, benchmarking

The T3 instances are all burstable, but they come with the \"unlimited\" feature toggled on by default.

2023-09-10 00:00:00
benchmarking

The t3/t4 class is notoriously problematic when you get to reasonable loads because of their burstable nature.

2023-09-10 00:00:00
benchmarking

I ran the popular Geekbench 5 benchmark against t3.medium, t3a.medium and t4g.medium Results are below (higher score is better).

2023-02-21 00:00:00
benchmarking

We ran the tests for T3.medium vs T3.small vs T4g.medium vs T4g.small AWS RDS PostgreSQL instances and found out that all of them were very similar when it came to the speed of write/read operations when you're performing an operation that is supposed to take a short time ~ 1-5 seconds. However, where the .medium instances (both T3 and T4) really stood out was the creation of indexes on a large table and text search through a large table. In that case both T3 and T4 .medium instances were about 2x faster than the .small instances. T3 was a bit better in our tests (like 5-10%). So I'd say go with T3 and choose the RAM size depending on the largest table in your DB.

2022-02-04 00:00:00
memory_usage, benchmarking

In this session, come learn about Amazon EC2 burstable instance types, new features, and the new T4g instances.

2021-05-02 00:00:00

Amazon EC2 burstable instance types, T3, T3a, and next-generation T4g, offer a quick and easy way to run workloads more efficiently, saving you money without sacrificing performance when you need it.

2021-05-02 00:00:00
benchmarking, cost_savings

I think the discrepancies can be attributed to the choice of the t-style instances. They are generally over committed.

2023-09-10 00:00:00
benchmarking

The T3 instances are all burstable, but they come with the \"unlimited\" feature toggled on by default.

2023-09-10 00:00:00
benchmarking

Aren\'t \'t\' instances burst instances? They need to be under constant load for a long time before their burst credits for CPU, memory, network and EBS run out, after which they fall back on their baseline performance.

2023-09-10 00:00:00
memory_usage, benchmarking

The t3/t4 class is notoriously problematic when you get to reasonable loads because of their burstable nature.

2023-09-10 00:00:00
benchmarking

We ran the tests for T3.medium vs T3.small vs T4g.medium vs T4g.small AWS RDS PostgreSQL instances and found out that all of them were very similar when it came to the speed of write/read operations when you're performing an operation that is supposed to take a short time ~ 1-5 seconds. However, where the .medium instances (both T3 and T4) really stood out was the creation of indexes on a large table and text search through a large table. In that case both T3 and T4 .medium instances were about 2x faster than the .small instances. T3 was a bit better in our tests (like 5-10%). So I'd say go with T3 and choose the RAM size depending on the largest table in your DB.

2022-02-04 00:00:00
memory_usage, benchmarking

I ran the popular Geekbench 5 benchmark against t3.medium, t3a.medium and t4g.medium Results are below (higher score is better).

2023-02-21 00:00:00
benchmarking

I ran the popular Geekbench 5 benchmark against t3.medium, t3a.medium and t4g.medium Results are below (higher score is better).

2023-02-21 00:00:00
benchmarking

When using them, it’s equally important to ensure that you’re using the right size of instance and to know when you should consider transitioning back to a fixed instance.

2023-05-24 00:00:00

We ran the tests for T3.medium vs T3.small vs T4g.medium vs T4g.small AWS RDS PostgreSQL instances and found out that all of them were very similar when it came to the speed of write/read operations when you're performing an operation that is supposed to take a short time ~ 1-5 seconds. However, where the .medium instances (both T3 and T4) really stood out was the creation of indexes on a large table and text search through a large table. In that case both T3 and T4 .medium instances were about 2x faster than the .small instances. T3 was a bit better in our tests (like 5-10%). So I'd say go with T3 and choose the RAM size depending on the largest table in your DB.

2022-02-04 00:00:00
memory_usage, benchmarking

The best way to get started with T3 instances is to audit your existing EC2 instances and identify areas where you may not need constant CPU performance.

2023-05-24 00:00:00
benchmarking

AWS T3 instances are a great way to lower your costs for processes that involve periodic bursts of CPU usage.

2023-05-24 00:00:00
cost_savings

When your CPU utilization is equal to your earning rate, that’s the baseline percentage where you break even. You are saving money when your instance’s average CPU utilization is below the baseline.

2023-05-24 00:00:00
cost_savings

You realize cost benefits when you spend credits at a slower rate than you’re earning them.

2023-05-24 00:00:00
cost_savings

The decision to use T3 instances ultimately depends on the balance between earning credits at a constant rate and consuming credits at a rate proportional to CPU utilization.

2023-05-24 00:00:00
cost_savings

You can even use AWS T3 instances to roll your own AWS services that have unnecessarily large default capacities.

2023-05-24 00:00:00

Another common use case is when you don’t need any compute power at certain times.

2023-05-24 00:00:00

For example, at CloudForecast, we consume a lot of CPU power generating client reports, but these tasks only run occasionally, which means that we can use T3 instances to dramatically cut down on costs compared to EC2 instances.

2023-05-24 00:00:00
memory_usage, cost_savings

T3 instances are “unlimited” by default, which means that you will generate surplus credit charges if you spend more credits than you generate.

2023-05-24 00:00:00
cost_savings

AWS EC2 T3 instances are low-cost burstable general instances that provide a baseline level of CPU performance with the ability to burst CPU usage at any time. They are perfect for applications with moderate (or even no) CPU usage that experience temporary spikes in use.

2023-05-24 00:00:00
benchmarking, cost_savings

Rather than paying a fixed amount for always-on EC2 processing power, T3 instances generate credits when the CPU runs below a baseline that you can use when bursting above the baseline.

2023-05-24 00:00:00
cost_savings

AWS T3 instances in EC2 are a great example of an opportunity to save money on certain services. Rather than paying a fixed amount for EC2’s always-on CPU usage, T3 instances enable you to only pay for the CPU usage that you need in applications that don’t require a constant level of performance.

2023-05-24 00:00:00
benchmarking, cost_savings

My main concern is a higher maximum CPU capacity. Within that requirement, I'd like to go for the cheapest solution. Indeed I'm currently always using more than the baseline performance, so consistently paying for additional CPU credits. And actually t3.medium offers the same amount of CPU credits as t3.small (24/hour), it just has double RAM (which I don't need). So for more CPU capacity, it seems like either t3.xlarge or c5.large is the way to go.

2020-01-10 00:00:00
cpu_credits, memory_usage, benchmarking

t3.medium would not be faster than a t3.small, it would just have more RAM and CPU credits.

2020-01-10 00:00:00
cpu_credits, memory_usage, benchmarking

Thank you for this article. We have T instances for EC2 and RDS and we are expecting some very strange performance behavior. Do you have plan to test RDS?

2025-10-03 00:00:00
benchmarking

Thanks for the nice write-up Tibor, I wonder if you always had enough CPU credits remaining as these burstable CPU instances consume from them and the performance can vary greatly if you consume all of them.

2025-10-03 00:00:00
cpu_credits, benchmarking

This is super well documented by aws themselves and if you understood how they work before creating the article then you probably would not have written it. Please do research before writing scare articles just for clicks. That’s just lame brother.

2025-10-03 00:00:00

Would you mind running the tests on the new ARM instance types? I’m thinking that those would save even more money over the t types and probably won’t be oversubscribed yet.

2025-10-03 00:00:00
cost_savings

Jeremy, the documentation talks about the cpu credit system. Tiber is refering to a totally different problem. And with such a rude language you are embarrassing yourself.

2025-10-03 00:00:00
cpu_credits, benchmarking

The purpose of the article is not to scare people it is just to raise a behaviour which is not clear for everyone. I specially mentioned I was using Unlimited instances in this test. You are saying as well: “An Unlimited instance can sustain high CPU performance for any period of time whenever required.” This sentence for me and for 99% of the people would mean I can get a stable performance with T3 instance types as well. But that is not true as you can see. That’s the whole point of the post to show even with Unlimited you can have performance degradation if you have some noisy neighbours.

Percona
2025-10-03 00:00:00
benchmarking

Before any actions, I would check the Instance log screenshot to verify that the instance boot process finished successfully. Also, check compatibility to understand if your resizing options make sense When encountering the issue of not being able to SSH into an EC2 t3 instance after upgrading from t2, two things need to be checked: * Security group rules: Verify that the inbound rules in the security group allow access on port 22 from the new IP address. * ENA drivers: Ensure that the Elastic Network Adapter (ENA) drivers are enabled.

2023-02-14 00:00:00

Per benchmarks at photographerstechsupport.com, t3 instances tend to be 10 to 20% faster than their equivalently spec'd t3a counterparts.

2020-02-19 00:00:00
benchmarking

Restarting a EC2 instance might make this EC2 instance\'s IP change, please check if IP is the same first.

2023-02-14 00:00:00

I have decided to upgrade these machines to t3 or t3a class instances to save some cost. I have followed these steps as per the documentation: 1. Stop the instance 2. Instance Settings -> Change Instance type to t3 3. Start the Instance Everything works fine, no error anywhere in these 3 steps. But after the instance is in the `Running` state with both `system and instance checks` passed, I am not able to SSH on these machines.

2023-02-14 00:00:00
cost_savings

Thank you for this article. We have T instances for EC2 and RDS and we are expecting some very strange performance behavior. Do you have plan to test RDS?

2025-10-03 00:00:00
benchmarking

The purpose of the article is not to scare people it is just to raise a behaviour which is not clear for everyone. I specially mentioned I was using Unlimited instances in this test. You are saying as well: “An Unlimited instance can sustain high CPU performance for any period of time whenever required.” This sentence for me and for 99% of the people would mean I can get a stable performance with T3 instance types as well. But that is not true as you can see. That’s the whole point of the post to show even with Unlimited you can have performance degradation if you have some noisy neighbours.

Percona
2025-10-03 00:00:00
benchmarking

Yes, I was monitoring the CPU credit as well and did not have any impact on the performance. There were times wen credit went down but QPS went up and there were times when Credit went up but QPS went down… I could not find any correlation between performance and CPU credit on Unlimited instances.

Percona
2025-10-03 00:00:00
cpu_credits, benchmarking

Thanks for the nice write-up Tibor, I wonder if you always had enough CPU credits remaining as these burstable CPU instances consume from them and the performance can vary greatly if you consume all of them.

2025-10-03 00:00:00
cpu_credits, benchmarking

Jeremy, the documentation talks about the cpu credit system. Tiber is refering to a totally different problem. And with such a rude language you are embarrassing yourself.

2025-10-03 00:00:00
cpu_credits, benchmarking

This is super well documented by aws themselves and if you understood how they work before creating the article then you probably would not have written it. Please do research before writing scare articles just for clicks. That’s just lame brother.

2025-10-03 00:00:00

Would you mind running the tests on the new ARM instance types? I’m thinking that those would save even more money over the t types and probably won’t be oversubscribed yet.

2025-10-03 00:00:00
cost_savings

The decision to use T3 instances ultimately depends on the balance between earning credits at a constant rate and consuming credits at a rate proportional to CPU utilization. You realize cost benefits when you spend credits at a slower rate than you’re earning them.

2023-05-24 00:00:00
cost_savings

AWS T3 instances are a great way to lower your costs for processes that involve periodic bursts of CPU usage.

2023-05-24 00:00:00
cost_savings

There are many different workloads that fit the burstable pattern. The most common use case is when you don’t need full power all the time.

2023-05-24 00:00:00

I ran the popular Geekbench 5 benchmark against t3.medium, t3a.medium and t4g.medium Results are below (higher score is better).

2023-02-21 00:00:00
benchmarking

The pricing of AWS T3 instances is simple: Rather than paying a fixed amount for always-on EC2 processing power, T3 instances generate credits when the CPU runs below a baseline that you can use when bursting above the baseline.

2023-05-24 00:00:00
cost_savings

AWS EC2 T3 instances are low-cost burstable general instances that provide a baseline level of CPU performance with the ability to burst CPU usage at any time. They are perfect for applications with moderate (or even no) CPU usage that experience temporary spikes in use.

2023-05-24 00:00:00
benchmarking, cost_savings

AWS T3 instances in EC2 are a great example of an opportunity to save money on certain services. Rather than paying a fixed amount for EC2’s always-on CPU usage, T3 instances enable you to only pay for the CPU usage that you need in applications that don’t require a constant level of performance.

2023-05-24 00:00:00
benchmarking, cost_savings

My main concern is a higher maximum CPU capacity. Within that requirement, I'd like to go for the cheapest solution. Indeed I'm currently always using more than the baseline performance, so consistently paying for additional CPU credits. And actually t3.medium offers the same amount of CPU credits as t3.small (24/hour), it just has double RAM (which I don't need). So for more CPU capacity, it seems like either t3.xlarge or c5.large is the way to go.

2020-01-10 00:00:00
cpu_credits, memory_usage, benchmarking

t3.medium would not be faster than a t3.small, it would just have more RAM and CPU credits.

2020-01-10 00:00:00
cpu_credits, memory_usage, benchmarking

Anything where your CPU usage varies in the short term but is consistent over 24 hours will likely be cheaper when switched to a T3.

2018-01-11 00:00:00
cost_savings

We ran the tests for T3.medium vs T3.small vs T4g.medium vs T4g.small AWS RDS PostgreSQL instances and found out that all of them were very similar when it came to the speed of write/read operations when you're performing an operation that is supposed to take a short time ~ 1-5 seconds. However, where the .medium instances (both T3 and T4) really stood out was the creation of indexes on a large table and text search through a large table. In that case both T3 and T4 .medium instances were about 2x faster than the .small instances. T3 was a bit better in our tests (like 5-10%). So I'd say go with T3 and choose the RAM size depending on the largest table in your DB.

2022-02-04 00:00:00
memory_usage, benchmarking

If your instance’s average CPU over 24 hours metrics is at or below the baseline, congratulations: you’ve hit the t3 instance sweet spot and are saving money!

2018-01-11 00:00:00
cost_savings

These are cost-effective instances which offer great price/performance for workloads that use moderate CPU, with the option to burst to high CPU usage whenever needed.

2018-01-11 00:00:00
benchmarking, cost_savings

Per benchmarks at photographerstechsupport.com, t3 instances tend to be 10 to 20% faster than their equivalently spec'd t3a counterparts. I notice that the precision of some of the benchmark values is low enough (i.e. 0.06 vs 0.07, reported only to the nearest hundredth) that the actual difference could be anywhere between ~0 and 26%. However, based on multiple values it does seem the difference is about 15% overall. This is reasonably close to the price difference of ~9%, making either choice a good option, depending on the compute performance need.

2020-02-19 00:00:00
benchmarking, cost_savings

I think the discrepancies can be attributed to the choice of the t-style instances. They are generally over committed.

2023-09-10 00:00:00
benchmarking

The T3 instances are all burstable, but they come with the \"unlimited\" feature toggled on by default.

2023-09-10 00:00:00
benchmarking

Aren\'t \'t\' instances burst instances? They need to be under constant load for a long time before their burst credits for CPU, memory, network and EBS run out, after which they fall back on their baseline performance.

2023-09-10 00:00:00
memory_usage, benchmarking

The t3/t4 class is notoriously problematic when you get to reasonable loads because of their burstable nature.

2023-09-10 00:00:00
benchmarking

My main concern is a higher maximum CPU capacity. Within that requirement, I'd like to go for the cheapest solution. Indeed I'm currently always using more than the baseline performance, so consistently paying for additional CPU credits. And actually t3.medium offers the same amount of CPU credits as t3.small (24/hour), it just has double RAM (which I don't need). So for more CPU capacity, it seems like either t3.xlarge or c5.large is the way to go.

2020-01-10 00:00:00
cpu_credits, memory_usage, benchmarking

t3.medium would not be faster than a t3.small, it would just have more RAM and CPU credits.

2020-01-10 00:00:00
cpu_credits, memory_usage, benchmarking

The best way to get started with T3 instances is to audit your existing EC2 instances and identify areas where you may not need constant CPU performance. The lowest hanging fruit is usually continuous integration (CI), test and development environments, and virtual desktops.

2023-05-24 00:00:00
benchmarking, development

AWS T3 instances are a great way to lower your costs for processes that involve periodic bursts of CPU usage. When using them, it’s equally important to ensure that you’re using the right size of instance and to know when you should consider transitioning back to a fixed instance.

2023-05-24 00:00:00
cost_savings

When your CPU utilization is equal to your earning rate, that’s the baseline percentage where you break even. You are saving money when your instance’s average CPU utilization is below the baseline.

2023-05-24 00:00:00
cost_savings

The decision to use T3 instances ultimately depends on the balance between earning credits at a constant rate and consuming credits at a rate proportional to CPU utilization. You realize cost benefits when you spend credits at a slower rate than you’re earning them.

2023-05-24 00:00:00
cost_savings

You can even use AWS T3 instances to roll your own AWS services that have unnecessarily large default capacities. For instance, NAT Gateways and Redis nodes support bursts of up to 10 Gbps by default. You could spin up a free T3 Micro with a NAT AMI to eliminate or mitigate these costs if you don’t need that much.

2023-05-24 00:00:00
cost_savings

Some of the most common use cases include: Virtual Desktops, CI or Build Servers, Development & Testing, Small- to Mid-sized Databases

2023-05-24 00:00:00
development

Another common use case is when you don’t need any compute power at certain times. For example, you may use virtual desktops during the work week, but you don’t need any compute power during the weekends when employees are gone.

2023-05-24 00:00:00

T3 instances are “unlimited” by default, which means that you will generate surplus credit charges if you spend more credits than you generate. You can avoid these charges by switching to the “standard” mode or using tools like CloudForecast to spot excess charges early-on and address any problems.

2023-05-24 00:00:00
cost_savings

The most common use case is when you don’t need full power all the time.

2023-05-24 00:00:00

Rather than paying a fixed amount for always-on EC2 processing power, T3 instances generate credits when the CPU runs below a baseline that you can use when bursting above the baseline. Any unused credits carry over into future billing periods.

2023-05-24 00:00:00
cost_savings

We ran the tests for T3.medium vs T3.small vs T4g.medium vs T4g.small AWS RDS PostgreSQL instances and found out that all of them were very similar when it came to the speed of write/read operations when you're performing an operation that is supposed to take a short time ~ 1-5 seconds. However, where the .medium instances (both T3 and T4) really stood out was the creation of indexes on a large table and text search through a large table. In that case both T3 and T4 .medium instances were about 2x faster than the .small instances. T3 was a bit better in our tests (like 5-10%). So I'd say go with T3 and choose the RAM size depending on the largest table in your DB.

2022-02-04 00:00:00
memory_usage, benchmarking

T3 instances have Intel Xeon Platinum 8000 series processors with a sustainable all-core turbo CPU clock speed of up to 3.1 GHz. They are 10% cheaper than the older T2 instances and offer up to a 30% better price to performance ratio.

2023-05-24 00:00:00
benchmarking, cost_savings

AWS EC2 T3 instances are low-cost burstable general instances that provide a baseline level of CPU performance with the ability to burst CPU usage at any time. They are perfect for applications with moderate (or even no) CPU usage that experience temporary spikes in use.

2023-05-24 00:00:00
benchmarking, cost_savings

AWS T3 instances in EC2 are a great example of an opportunity to save money on certain services. Rather than paying a fixed amount for EC2’s always-on CPU usage, T3 instances enable you to only pay for the CPU usage that you need in applications that don’t require a constant level of performance.

2023-05-24 00:00:00
benchmarking, cost_savings

I ran the popular Geekbench 5 benchmark against t3.medium, t3a.medium and t4g.medium Results are below (higher score is better).

2023-02-21 00:00:00
benchmarking

If your application doesn’t require a specific processor try the cheaper one first. Bench marking and analyzing performance is the best approach, it can be a deep rabbit hole though. Burst performance is great when your application requires that, but if the traffic is sustained then a M instance may be a better choice.

2025-10-03 00:00:00
benchmarking, cost_savings

For T3 and T3a instance types Unlimited mode is turned on by default. This is excellent, as we remove the risk of a production outage, but gain the risk of increased costs.

2025-10-03 00:00:00
cost_savings

My main concern is a higher maximum CPU capacity. Within that requirement, I'd like to go for the cheapest solution. Indeed I'm currently always using more than the baseline performance, so consistently paying for additional CPU credits. And actually t3.medium offers the same amount of CPU credits as t3.small (24/hour), it just has double RAM (which I don't need). So for more CPU capacity, it seems like either t3.xlarge or c5.large is the way to go.

2020-01-10 00:00:00
cpu_credits, memory_usage, benchmarking
Load More
Similar Instances to
t3.medium

Consider these:

Feedback

We value your input! If you have any feedback or suggestions about this t4g.nano instance information page, please let us know.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.