SendGrid vs Amazon SES

SendGrid is a managed product with two distinct workspaces

SendGrid makes sense when a B2B SaaS wants a product team to operate email without assembling every screen and event route. Its Email API covers application messages such as invitations, password resets, receipts, invoices, usage warnings, and security notices. SMTP relay keeps older services moving while newer services adopt the API. Dynamic templates give the team a place to maintain layout and variables, while application code chooses the template and supplies the data. The important boundary is that SendGrid manages the delivery service, but the company still owns message truth, consent, and business context.

Marketing Campaigns is a second product rather than a hidden feature of the Email API. It gives a growth or lifecycle team contact storage, campaign composition, scheduling, and its own contact and monthly-send allowances. A company can use the two products together, but it should forecast them separately. A campaign editor should not be able to change the delivery behavior of a password reset, and an engineer responsible for invoices should not have to administer every newsletter list. Define owners, sender identities, unsubscribe groups, and a suppression handoff before the first campaign is scheduled.

Subusers are useful when several products or environments share a commercial relationship but need distinct access and reporting. Give each subuser a narrow purpose, naming convention, API key policy, and event consumer. A parent account is not a substitute for a message inventory. Keep the internal event identifier, account identifier, template alias, consent state, and final delivery outcome in the company’s own systems. When a customer asks why an invoice was late, support should not depend on a console search that may have a different retention or access policy.

The Event Webhook is central to an application-owned workflow. Send delivery, bounce, block, complaint, and engagement events to an idempotent endpoint, verify the signature, and store the provider identifier next to the business event. The endpoint should tolerate retries, out-of-order messages, and a temporary provider outage. Build a dead-letter path and an operator view for events that cannot be associated with a known message. The provider can report what happened; your application decides whether to retry, suppress, notify a user, or open an incident.

SendGrid lists Email API Pro at $89.95 per month for the 100,000-email selector point and includes dedicated IP access there. A dedicated IP should be a deliberate operating choice, not a badge. The sender needs authenticated domains, a stable volume pattern, warm-up, complaint review, and someone who will respond to a reputation change. Smaller teams can begin on shared infrastructure while they establish those habits. Twilio support tiers and account administration can be valuable when a team wants an escalation path that sits alongside its own runbook.

• Give Email API and Marketing Campaigns separate owners, forecasts, access reviews, and consent documentation.
• Use subusers for genuine product or environment boundaries and rotate keys by service.
• Send Event Webhook events to a verified, idempotent consumer with retries and a dead-letter path.
• Keep a company-owned message ledger so support can explain an event without relying on a vendor screen.
• Treat dedicated IP access as a warm-up and reputation program, not as an automatic deliverability improvement.

Amazon SES is infrastructure inside the AWS operating model

Amazon SES is a good fit when the team already thinks in AWS accounts, regions, IAM roles, CloudWatch alarms, SNS topics, Lambda functions, and infrastructure-as-code. The service supplies the sending engine and the API or SMTP interface. The team decides how to represent templates, approvals, retries, suppression, event routing, dashboards, and operator access. That control can be a strength for a platform group with established AWS practices. It can also be a surprise for a marketing or product team expecting a ready-made email workspace.

The AWS console is the starting point for identities, quotas, configuration sets, production status, and deliverability controls. New accounts begin in the SES sandbox, so a launch plan needs identity verification and a production access request. The request should describe the sending use case, expected volume, recipient permission, bounce and complaint handling, and the domains involved. Treat approval as a dependency in the project schedule. A service that works in a developer account is not yet a production mail path until quotas, identities, regions, and access have been reviewed.

IAM is the main difference in day-to-day administration. Create roles that can send through the intended region and configuration set without granting unrelated account privileges. Separate deployment permissions from sending permissions. Use temporary credentials for workloads where practical, keep SMTP credentials out of source control, and review which service can publish to an event destination. AWS accounts can isolate environments, but they also create more invoices, quotas, identities, and operational runbooks. Choose the boundary that the people on call can explain at 03:00.

Configuration sets give SES a place to attach event destinations and sending options to a stream. Use them to route delivery, bounce, complaint, and other outcomes to SNS, CloudWatch, or another AWS destination, then connect those events to a durable internal ledger. A configuration set is not a campaign editor. It is an infrastructure control that helps the platform team observe and classify traffic. Name sets by product, environment, region, and message class, and make the choice explicit in application configuration so a migration cannot silently send production mail through a test path.

The Virtual Deliverability Manager gives an AWS-native team a deliverability view and recommendations inside the AWS workflow. It does not remove the need for permissioned recipients, good authentication, consistent content, bounce suppression, and incident ownership. SES also offers standard and managed dedicated IP choices. Standard IPs put more allocation and warm-up responsibility on the sender; managed IPs change that operating model and should be compared with the team’s volume and monitoring needs. Amazon SES lists Essentials at $0.16 per 1,000 emails for 0–10 million emails per month, while Pro lists $0.22 per 1,000 and a $105 per account per region monthly term.

• Plan sandbox exit and production access approval before the first customer-facing send.
• Use IAM roles and narrowly scoped policies for sending, configuration changes, event publishing, and deployment.
• Name configuration sets by region, environment, product, and message class, then make the selection visible in code.
• Send SES events to a durable internal ledger through the chosen AWS destinations.
• Compare standard and managed dedicated IPs with the team’s warm-up, monitoring, and reputation responsibilities.

The marketing question separates the products

SendGrid is the more direct choice when a B2B SaaS wants application email and a marketing operation in one vendor family. Marketing Campaigns has a contact model, an editor, schedules, and plan allowances that a growth team can understand without building an internal console. SendGrid lists a free Marketing Campaigns plan for up to 2,000 contacts and 6,000 emails per month. Paid Basic starts at $15 per month, and the selector includes larger contact and send points. Those limits are separate from the Email API volume, so the budget should show both lines.

Amazon SES has no built-in marketing UI. That is not a defect when the company already has a campaign system or wants to keep audience and consent logic in its own application. It becomes a project when marketing expects drag-and-drop composition, list management, approval flows, scheduling, segmentation, unsubscribe screens, and campaign reporting. The team must connect another product to SES or build those surfaces. Price the integration, data synchronization, and support path instead of assuming the low per-message number includes a campaign operation.

A useful architecture can still pair the products with a third-party campaign system. SendGrid may remain the managed transactional provider while a separate system owns newsletters. SES may remain the infrastructure layer while an external campaign tool submits messages through a controlled integration. In either arrangement, decide where consent is authoritative, how suppression travels in both directions, which domain sends each class, and who can change a template. A campaign contact count should never be confused with an application send count.

The choice therefore follows the team’s operating model. Pick SendGrid if the company wants a managed product and a ready-made marketing surface. Pick SES if the company is already AWS-native, has an engineering owner for the mail subsystem, and prefers to pay for messages while assembling the rest. If neither team can own the missing work, the cheapest line item will not be the cheapest system to operate.

• Model Email API and Marketing Campaigns as separate SendGrid products with separate limits.
• On SES, budget for the campaign UI, contact sync, approval flow, unsubscribe path, and reporting that a marketing team needs.
• Choose one consent authority and document how suppression is synchronized across transactional and campaign systems.
• Keep campaign and application sender identities distinct so reputation and incident response stay understandable.

Worked cost scenario: 250,000 application emails each month

Consider a B2B SaaS that sends 250,000 application emails each month: 80,000 invitations and verification messages, 65,000 billing notices, 55,000 workflow alerts, and 50,000 account or security messages. The team needs API delivery, templates, bounce and complaint events, and a monitored production sender. It does not need a marketing editor in this first budget. The calculation uses a published SES rate and does not invent a SendGrid price between selector points.

Amazon SES lists Essentials at $0.16 per 1,000 emails for the 0–10M monthly range. The arithmetic is 250,000 ÷ 1,000 = 250 billing units; 250 × 0.16 USD = 40 USD per month; 40 USD × 12 = 480 USD per year. That is the SES Essentials sending line before any separate AWS support, event destination, data transfer, attachment, or dedicated IP costs. If the team selected SES Pro instead, the message arithmetic would be 250 × 0.22 USD = 55 USD per month, while the listed $105 per account per region term would also need to be considered.

SendGrid’s selector points list Essentials at $19.95 for 50,000 emails and $34.95 for 100,000 emails. They do not publish a 250,000-email Essentials point in the material used for this page, so SendGrid pricing at 250,000 is pricing on request rather than an interpolation. That distinction matters in a finance review: a clear custom-price line is more honest than multiplying a lower point and presenting the result as a plan. SendGrid Pro does list $249 per month at 300,000 emails, which is a nearby named point but not the same volume.

For a smaller 50,000-email comparison, SendGrid lists Essentials at $19.95 per month. SES Essentials arithmetic is 50 × 0.16 USD = 8 USD per month, or 12 × 8 USD = 96 USD per year. SendGrid arithmetic is 12 × $19.95 = 239.40 USD per year. The difference is 239.40 USD - 96 USD = 143.40 USD per year before support, operations, campaign tools, and other add-ons. The lower SES charge is meaningful, but it does not answer who will build the screens and run the AWS controls.

A complete budget should keep base sending, campaign contacts, dedicated IPs, support, event processing, storage, template work, and operator time as separate lines. A team that selects SendGrid may pay more for a named plan and receive a managed console, Event Webhook, subusers, support options, and a marketing product. A team that selects SES may pay less for message units and spend more engineering time on IAM, configuration sets, dashboards, production access, and campaign integration. The right comparison is the total operating model for the stated workload.

1. Freeze the monthly message definition, including retries, tests, and attachments.
2. Use SES’s published $0.16 per 1,000 Essentials rate for 250,000 messages: 250 × $0.16 = $40.
3. Use a named SendGrid selector point or request a price; do not interpolate the missing 250,000 point.
4. Add support, event routing, dedicated IP, campaign, and operator lines separately.
5. Reconcile the provider invoice with the internal message ledger after the first full month.

Migration notes for a provider change

Moving between SendGrid and SES is a message-contract migration, not a credential replacement. Inventory every sender domain, return path, template, API call, SMTP client, category, subuser, configuration set, event destination, suppression rule, campaign contact source, and owner. Mark which traffic is transactional, which is marketing, and which must never share a reputation path. The inventory should explain what happens on a hard bounce, a temporary failure, a complaint, an unsubscribe, and a provider outage.

Start with domain and access work. For SendGrid, review subusers, API keys, sender authentication, dynamic template aliases, Event Webhook signatures, and the account support path. For SES, verify the region, identities, IAM roles, sandbox status, production access, quotas, configuration sets, and event destinations. Confirm SPF, DKIM, DMARC, return-path, link tracking, and TLS expectations. Lower DNS TTL ahead of a cutover where practical, but keep old DNS entries until the new path has delivered a controlled sample.

Template conversion needs representative fixtures. Export subject, preheader, variables, fallback values, localization, unsubscribe behavior, and attachment rules. Rebuild SendGrid dynamic templates as the destination supports them, or move composition into the application when SES is the destination. Render a long company name, a missing optional field, a non-Latin name, an invoice, a failed payment, and a security warning. A message can pass a syntax check and still have a broken link, clipped button, or misleading fallback.

Event processing must be tested independently of the send request. Send known messages through the new provider, force a controlled bounce where the vendor supports it, and verify delivery, complaint, suppression, retry, and dead-letter behavior. For SES, check that the configuration set is attached in every sending path and that the event destination receives events in the intended region. For SendGrid, verify Event Webhook signature handling and duplicate-event tolerance. Store both the internal message identifier and the provider identifier so support can trace a message across the migration.

Ramp by message class rather than switching every sender at once. Begin with internal accounts, then invitations, routine notices, billing, and security messages. Compare delivery, bounce, block, complaint, latency, and support outcomes. If a dedicated IP is involved, schedule authentication and warm-up before moving meaningful volume. Keep the old provider available for a short overlap, but prevent dual-sending of the same business event. Once the new path is stable, revoke old keys, remove stale DNS assumptions, close unused subusers or IAM roles, and preserve a support-readable mapping.

1. Create a message matrix with event, sender, template, recipient class, provider object, suppression rule, and owner.
2. Verify domains, DNS, regions, IAM or account access, quotas, and production onboarding gates.
3. Rebuild templates and test visual, localization, link, fallback, and attachment behavior.
4. Implement webhook or AWS event consumers with signature checks, idempotency, retries, and replay protection.
5. Ramp one class at a time and compare provider events to the internal ledger.
6. After overlap, revoke old credentials and archive the migration map for support and security review.

Who should pick which provider?

Pick SendGrid when the team wants a managed product that a communications owner can run alongside engineering. It fits a company that needs a visual template workflow, an Email API, SMTP for older services, subusers for organizational boundaries, Event Webhook data, support tiers, and a Marketing Campaigns workspace. The tradeoff is a broader vendor surface with two products, two sets of limits, and two ownership conversations. That is a reasonable cost when the alternative is building a campaign and operations layer around raw infrastructure.

Pick Amazon SES when the team already runs on AWS and wants the mail path to behave like another infrastructure component. It fits an organization that can own IAM, regions, configuration sets, event destinations, sandbox exit, production quotas, deliverability review, and dedicated IP decisions. The low per-message charge is attractive for high-volume application mail. The tradeoff is that SES does not hand a marketing team a campaign editor, contact workspace, or approval calendar. Those capabilities must come from another service or the company’s own product.

A team that wants managed delivery should start its evaluation with SendGrid’s Email API and Marketing Campaigns boundaries. A team already running on AWS should start with an SES account and write down the missing runbooks before celebrating the message price. In either case, keep consent, suppression, template version, and business-event ownership inside the company. The provider should be replaceable infrastructure, not the only place where the meaning of a customer email exists.

Revisit the decision when the workload changes. A startup sending 50,000 notifications may accept SendGrid’s $19.95 Essentials price for an uncomplicated launch, or SES’s $8 Essentials arithmetic if its AWS team already has the controls. A growing sender at 300,000 messages may value SendGrid Pro’s named $249 selector point and managed workflow, while an AWS-native team may continue with usage billing and invest in its platform. The correct answer is the one the people on call can operate and explain.