When would you move an Amazon SES workload from the shared IP pool onto dedicated IPs, and what does that commit you to?

## The actual decision Interviewers ask this because the wrong answer is enthusiastic. Dedicated IPs sound like the professional choice, so candidates recommend them by reflex. The right answer starts by defending the shared pool and names the conditions under which leaving it is justified. ## What the shared pool gives you On shared IPs your mail leaves alongside many other SES customers'. Consequences: - **No warm-up.** The addresses already have a long, established history with every major receiver. - **No per-IP cost.** - **Volume-tolerant.** Spiky or low sending is fine, because the addresses stay warm on aggregate traffic even when yours goes quiet for a week. - **Reputation is pooled**, and AWS actively polices the pool — that policing is the reason bounce and complaint thresholds are enforced on your account at all. The downside is the one everyone names: another customer's behaviour can, in principle, affect you. In practice AWS's enforcement makes this a much smaller effect than candidates assume, and it is rarely on its own a reason to move. ## What dedicated IPs give you, and what they take A dedicated IP is an address only you send from. The upside is isolation and control: your sending history is yours, some enterprise recipients and partners want a fixed, allow-listable address, and you can segment streams onto separate addresses. The costs are structural, not just financial: **Warm-up.** A brand-new address has no history. Blasting full volume from it on day one reads to receivers exactly like a spammer who just bought an address block — deferrals, spam-foldering, or outright blocks. Warm-up means ramping daily volume over a period of weeks, ideally sending your most-engaged recipients first, because opens and low complaints are what build the history. SES supports this with a warm-up mechanism that throttles how much of your traffic goes to a new dedicated IP while the rest overflows. **Sustained volume.** Reputation is a rolling window. An IP that sends heavily in December and nothing in January is partly cold again by February. This is why the guidance is consistent high volume — not a peak, a floor. A workload that sends a large campaign monthly and nothing between is a worse fit for dedicated IPs than one sending steadily every day at a fraction of that total. **Operational ownership.** Blocklist monitoring, per-IP reputation, warm-up plans for each new address — all now yours. ## Standard vs managed SES sells dedicated IPs two ways, and knowing the difference is the tell that you have used them: - **Standard** — you request the IPs, you own the warm-up plan and the volume distribution, you decide when to add another. - **Managed** — SES handles warm-up automatically and scales the number of IPs to your sending volume, adding and removing capacity as traffic changes. Managed removes most of the reasons a team gets dedicated IPs wrong. If the driver is "we want our own reputation" rather than "we need a specific fixed address to allow-list," managed is usually the better trade. You create a pool and choose the mode at creation time: ``` aws sesv2 create-dedicated-ip-pool \ --pool-name transactional --scaling-mode MANAGED ``` ## Pools and stream isolation A pool is assigned through a configuration set's delivery options, so each sending stream can use its own pool. This is the strongest architectural argument in the whole topic: put password resets and receipts on one pool and bulk marketing on another, and a marketing campaign that draws complaints cannot degrade the address your security email leaves from. Note the limit of that isolation — account-level bounce and complaint rates are still account-level, so a bad marketing stream can still put the whole account under review. Pools isolate *receiver-side IP reputation*, not your standing with AWS. ## When the answer is genuinely yes - Consistent, high daily volume — the order of hundreds of thousands of messages a month, sent steadily rather than in occasional bursts. - A partner or enterprise recipient requires a fixed address to allow-list. - You need hard separation between streams whose reputations must not mix. - You have a team that will actually monitor per-IP reputation and blocklists. If none of those hold, staying shared is the correct engineering answer and saying so confidently is the correct interview answer. ## Instrumenting the decision Whatever you choose, turn on Virtual Deliverability Manager. Its dashboard breaks delivery down by ISP and gives per-configuration-set visibility, and its advisor flags configuration problems — missing authentication, records that would hurt placement. It is how you find out whether an IP change actually helped, instead of arguing about it. Being able to name it, and to say you would measure before and after, is what makes this a principal-level answer rather than an opinion.