Amazon SES Managed Dedicated IPs: Warm-Up Guide

Why Dedicated IPs Still Matter in 2026

When you send through Amazon SES on a shared IP pool, you are one of many senders on the same address. AWS manages those pools carefully, but the fundamental problem does not go away: another sender's poor list hygiene, spam-trap hits, or complaint spike can damage a reputation you share but do not control. As mailbox providers have continued tightening their filtering, the question of which IP your mail originates from has become increasingly consequential. A dedicated IP isolates your reputation from everyone else on the platform, meaning your deliverability reflects your own sending behaviour and nothing else. Choosing the right type of dedicated IP, and then monitoring it properly once it is live, is the decision this guide is designed to help you make.

The Three Dedicated IP Options in Amazon SES

SES currently offers three paths to a dedicated sending address: Standard, Managed, and Bring Your Own IP (BYOIP). Each sits at a different point on the control-versus-convenience spectrum, and each carries its own cost structure.

Standard dedicated IPs cost $24.95 per IP address per month, regardless of sending volume. You request them, configure your own IP pools, and handle warm-up yourself, either manually or by enabling the built-in automatic warm-up option. You retain full control over which IP sends which traffic, and you can move addresses between pools as your programme evolves.

Managed dedicated IPs cost $15 per account per month, plus tiered per-email rates: $0.08 per 1,000 emails up to 10 million, $0.04 for 10 million to 50 million, and $0.02 for 50 million to 100 million monthly emails. There is no support request to raise. IPs are allocated automatically when you create a managed pool, and AWS handles warm-up, scaling, and ISP-level routing on your behalf.

BYOIP allows you to bring an IP range you already own into SES. The minimum block is a /24, meaning 256 addresses, at $24.95 per IP per month, producing a minimum monthly commitment of $6,387.20 before any per-email costs. BYOIP is only available with Standard dedicated IPs, not with Managed, and the range is locked to a single AWS Region. It is also worth noting that BYOIP on SES is a distinct mechanism from the broader AWS BYOIP feature used with EC2 or other services; the purpose here is preserving an established sending reputation, not reducing IPv4 costs.

In July 2026, AWS introduced three bundled pricing plans, Essentials, Pro, and Enterprise, which roll sending, Virtual Deliverability Manager, and at the higher tiers, managed dedicated IPs into a single per-email rate. Standard and BYOIP dedicated IPs remain pay-as-you-go extras on every plan. For senders evaluating the a la carte model described throughout this guide, the bundled plans are worth checking against your projected usage before committing to a configuration.

What Managed Dedicated IPs Actually Do

The Managed tier was introduced in late 2022 specifically to remove the operational burden of running dedicated IPs. The entire process of provisioning, warming up, scaling, and routing email across exclusive IP addresses is handled by AWS on your behalf. You create a managed pool through the SES console, CLI, or API, associate it with a configuration set, and begin sending. No support ticket, no warm-up spreadsheet, no manual pool adjustments.

The mechanism that makes this possible is an intelligent, per-ISP warm-up. Rather than applying a single time-based ramp across all mailbox providers, managed IPs track the warm-up level for each ISP individually. If you have been sending heavily to Gmail, your IPs are considered warm for Gmail but cold for other providers. If you then ramp up traffic to Outlook, SES increases volume to that ISP slowly while continuing at full pace for Gmail. This per-destination throttling is the most material difference between Managed and Standard dedicated IPs: Standard applies a static 45-day ramp across all ISPs, whereas Managed adapts continuously to your actual traffic pattern.

Scaling is equally automatic. If SES detects that an ISP supports a low daily send quota, the managed pool scales out to distribute traffic across more IP addresses, reducing the risk of hitting per-IP rate limits at any single provider. AWS uses recent sending performance and historical forecast models to continuously re-adjust sending volume and routing across the IP space, with the goal of maximising reputation and minimising the impact of bounced emails.

During the warm-up period, traffic that exceeds the current capacity of your dedicated IPs spills over into SES shared pools temporarily. As your dedicated IPs accumulate a positive sending history with each ISP, more of your traffic routes through them and less through the shared pool, until the dedicated IPs handle all volume independently. This spillover behaviour means Managed IPs are particularly well suited to senders with irregular or unpredictable volumes, where a Standard IP left idle between campaigns would lose its warm-up progress.

In October 2025, AWS added IP observability to Managed pools, giving you visibility into the exact IP addresses in use along with Microsoft SNDS metrics for those addresses. Previously, customers using Managed pools had no straightforward way to audit which addresses were actually sending their mail.

Standard Dedicated IPs: When Manual Control Is Worth It

Standard dedicated IPs make sense when you want granular control over your sending infrastructure and have the operational capacity to exercise it. They suit technically capable teams running predictable sending programmes at meaningful daily volumes, where the consistency of sending is itself part of what keeps the IPs warm.

With Standard IPs, you decide which pool handles transactional mail, which handles marketing campaigns, and how traffic is segmented between programmes that carry different complaint risk profiles. You can manually move IPs between pools and, if you know your engagement rates will support it, accelerate warm-up faster than the default 45-day schedule by adjusting your own volume ramp. This degree of control comes at the cost of ongoing attention: you must monitor your pools, respond to reputation signals, and scale manually when your sending volume grows.

If your sending patterns are highly irregular, Standard IPs become harder to justify. An IP that goes cold between large campaign sends will need to be re-warmed, and the fixed $24.95 per-IP charge applies whether the address is sending or sitting idle.

BYOIP: The Enterprise Case

BYOIP on Amazon SES is designed for a narrow but important use case: large enterprises that already own a range of IP addresses with an established sending reputation and want to preserve that history when migrating to AWS infrastructure. The minimum block you can transfer is a /24, giving you 256 addresses, and you must transfer the entire range. Individual IP transfers are not supported. The range must be registered to a business or institutional entity with an RIR and cannot be registered to an individual. Each range is locked to a single AWS Region, and you can bring up to five ranges per Region to an account.

The financial arithmetic is stark. At $24.95 per IP and a minimum of 256 addresses, the monthly floor is $6,387.20 before a single email is sent. That figure only makes sense if the IP range carries a multi-year positive reputation that would take many months and considerable risk to rebuild from scratch on fresh addresses. For any sender without an existing, clean IP range, BYOIP is not a practical option.

Shared Pools Versus Dedicated IPs: The Reputation Isolation Argument

Shared IP pools are the default for every new SES account, and they are sensible for lower-volume senders. AWS manages the pool's collective reputation by carefully controlling outbound traffic, and because many senders contribute volume simultaneously, the pool maintains a consistent sending pattern that ISPs find reassuring. For senders below roughly 50,000 emails per month, shared pools are typically the right choice.

The problem emerges at scale and at the margins of list quality. Because shared IPs are used by multiple SES customers, one sender's poor practices can affect the deliverability of others on the same address. You might maintain impeccable list hygiene, achieve low bounce rates, and generate strong engagement, yet still see inbox placement decline because a co-sender on your shared IP triggered a blocklist listing or drove up complaints. That is not a hypothetical edge case; it is an inherent structural risk of shared infrastructure.

A dedicated IP removes that risk entirely. After warm-up, your dedicated addresses are isolated from the SES shared pool, and your reputation reflects only your own sending behaviour. If your bounce rate is low and your engagement is strong, your reputation will show it. If you make a mistake, you bear the consequences of that mistake, but equally you are not penalised for someone else's.

What AWS Does Not Monitor for You

The auto warm-up feature is genuinely useful, and the observability improvements AWS added in 2025 have closed some meaningful gaps. However, warm-up completion is a point in time, not an ongoing state. Once your Managed IPs are fully warmed and carrying your full volume, AWS does not proactively alert you when things begin to go wrong.

AWS enforces a two-tier system on every account. A bounce rate above 5% or a complaint rate above 0.1% places your account under review. Push further, beyond 10% bounces or 0.5% complaints, and AWS may pause your ability to send entirely. The risk is that by the time AWS acts, significant damage has already been done to your IP reputation, and recovery from a blocklist listing or ISP-level filtering decision can take weeks.

Blocklist appearances are a particularly acute risk for dedicated IP senders because, on a shared pool, AWS absorbs and manages the collective reputation impact. On your dedicated IP, any listing is yours alone. AWS CloudWatch exposes a blacklisted IP metric, but it surfaces data at the account level and requires you to configure alarms manually. Third-party blocklists operate on their own schedules and are not all reflected in CloudWatch. A listing on a major blocklist such as Spamhaus can affect delivery at hundreds of receiving domains before you become aware of it through your own metrics.

The SES console's reputation dashboard shows bounce and complaint rates, and the Virtual Deliverability Manager (VDM) add-on provides more granular deliverability intelligence, but VDM carries its own separate cost. For teams that need continuous visibility without that additional expenditure, there is a gap between what AWS provides by default and what responsible IP management actually requires.

Building a Monitoring Stack Around Your Dedicated IPs

The foundation of any monitoring stack for SES is SNS event destinations. Create a configuration set with bounce and complaint event destinations pointing to an SNS topic, then subscribe your application endpoint or webhook handler to that topic. Every hard bounce and every spam complaint will arrive as a structured JSON payload that your application can act on immediately, adding the offending address to your suppression list before the next send. SES maintains an account-level suppression list for hard bounces automatically, but processing complaints in real time and acting on soft bounce patterns requires a handler you build and maintain.

CloudWatch alarms add a safety net at the account level. Configure an alarm on the Reputation.BounceRate metric to fire at 2%, well before the 5% review threshold. Set a matching alarm on complaint rate at 0.05%, well below the 0.1% level that triggers an account review. These alarms will not tell you which specific IP or sending identity is causing the problem, but they will catch a deteriorating trend before it reaches an enforcement boundary.

For blocklist monitoring, CloudWatch is not sufficient on its own. You need to query the major blocklist lookup services against each of your dedicated IP addresses on a regular schedule, ideally daily, and receive an alert the moment any address appears. This is operationally straightforward to automate, but it requires building and maintaining the integration yourself if you rely solely on AWS tooling.

How SES Monitor Closes the Gap

SES Monitor is built specifically around the monitoring gap that exists once AWS has finished the warm-up work. It connects to your account by receiving events from your existing SNS topic and requires no permission to send email on your behalf.

Every delivery, bounce, and complaint is tracked and measured against the AWS enforcement thresholds in real time. Alerts go out by email and webhook as bounces and complaints arrive, so you can act on a spike hours before it compounds into an account review. Each bounce and complaint notification includes the reason, the recipient address, and the specific message that triggered it, so list cleaning becomes a targeted operation rather than guesswork.

Per-domain dashboards show current and historic bounce and complaint rates alongside the AWS thresholds, making it straightforward to see which sending identity or campaign is driving a deterioration. Webhook integrations let you push suppression actions directly into your sending application the moment a complaint arrives, without needing to poll the SES API or build a custom Lambda function to bridge the gap.

Critically, none of this requires the Virtual Deliverability Manager add-on. SES Monitor operates independently of VDM, so teams that want continuous, real-time reputation visibility without the additional AWS cost have a practical alternative. For senders running Managed dedicated IPs, where AWS has handled the warm-up but ongoing reputation is entirely your responsibility, that independent monitoring layer is not optional. It is the operational complement to the infrastructure AWS provides.

Decision Checklist: Choosing Your Dedicated IP Tier

Before committing to a dedicated IP configuration, work through the following questions.

Do you send consistently above 50,000 emails per month? If not, shared pools are likely sufficient. Do you need to isolate the reputation of different email programmes from one another, for example transactional versus marketing? If yes, dedicated IPs with separate pools give you that isolation. Do you have the technical capacity to monitor and respond to reputation signals on an ongoing basis, and are your sending volumes predictable and consistent? Standard dedicated IPs may suit you. Do you need dedicated IP isolation without the operational overhead of manual warm-up and scaling, or do your sending volumes fluctuate significantly week to week? Managed dedicated IPs are almost certainly the right choice. Do you own a large, established IP range with a multi-year positive reputation that you cannot afford to rebuild? BYOIP is worth evaluating, with full awareness of the $6,387.20 monthly floor.

Summary and Next Steps

Amazon SES gives you three credible paths to dedicated IP sending in 2026, each suited to a different combination of volume, technical capacity, and operational budget. The Managed tier removes the most burdensome parts of IP management, handling warm-up per ISP, auto-scaling pools, and routing traffic intelligently across your dedicated addresses. Standard IPs offer full control for teams willing to invest the operational attention. BYOIP is a specialist option for enterprises with existing IP equity worth preserving. For senders evaluating costs, the bundled Essentials, Pro, and Enterprise plans introduced in mid-2026 are worth comparing against the a la carte rates before making a final decision.

Whatever tier you choose, the most important thing to understand is that warm-up completion is the beginning of IP management, not the end. Bounce rates drift, complaint rates creep, and blocklist listings appear without warning. AWS provides the tools to detect problems at the account level, but real-time per-event visibility, webhook-driven suppression, and independent blocklist monitoring require a layer of tooling that sits alongside the SES console rather than inside it. Setting that layer up before your first production send on a dedicated IP is the decision that will protect the reputation you spent weeks building.