AWS SES sending identities and per-service SMTP/API credentials were created in the eu-central-1 SES tenants and provisioned to requesters. Sender addresses were administratively limited or changed on request and primary contact persons and approval steps were recorded in Jira. Request metadata (expected 24‑hour and monthly volumes, attachment behavior, cost centre, and hard‑bounce contacts) were recorded and used to place accounts into operational categories (marketing vs system) and to set suppression/notification expectations. Credentials and other sensitive data were delivered to teams via the organisation’s secure vaults (Safe App / 1Password / Teams). CloudWatch logging was enabled when requested. During migrations to SES some test sends failed with the SMTP error “554 Message rejected: Email address is not verified” when identities had not been verified; onboarding/migration work therefore included verifying listed sender identities, clarifying approved sender/wildcard noreply patterns for internal services, and confirming contacts and volume limits before enabling sending.

Postfix-based hosts and application SMTP users were migrated from MX1 to AWS SES by switching relayhost entries to the appropriate AWS SES SMTP endpoints and replacing MX1 SASL credentials with SES SMTP credentials in smtp_sasl_password_maps; previous MX1 settings were retained as commented references for traceability. Application/sender migrations (for example the ernennungsportal sender) received provisioned SES SMTP credentials which were handed over securely—credentials were stored in 1Password and cutover coordination was handled via Microsoft Teams, with cost-center/ownership clarified before handover. Delivery and cutover success were confirmed by reviewing AWS SES send logs and Postfix/OTRS logs on the hosts (example host: cpgbrh2otrs1). Migration activities were coordinated with application teams to avoid accidental sending from test/dev environments and to ensure SMTP users and sender addresses were updated in tandem.

Investigation of SMTP and SES logs identified that the SES SMTP user exceeded the per-second send-rate threshold and returned SMTP 454 responses; this triggered the sending application to alternate SMTP routes and caused inconsistent sender addresses. Mitigation measures reduced observed 454 responses and stabilized the SMTP path usage; after the change the SMTP 454 errors ceased and invoice attachments were received with normal filenames. The attachment-extension anomaly was attributed to recipient-side mailserver/security handling rather than content corruption from SES.

Failures were traced to IAM principals lacking the ses:SendRawEmail permission scoped to the SES identity ARN, and/or to the SES sender identity not being authorized or verified. The resolution corrected the application's SMTP/IAM principal policy to include ses:SendRawEmail for the target SES identity ARN and ensured the required sender addresses/identities were authorized in SES. In the SMTP migration case the SMTP user/principal mapping to the new server was reconciled with IAM/SES and the SES identity re-authorized. After the IAM policy and sender-identity updates the applications (Auth0, Metabase) regained sending capability and SES retry/delay behavior returned to normal.

A credentials format compatible with the third-party product was supplied and delivered to the requester via the organization's secure vault channels (1Password / Teams). Providing SMTP credentials in a form the application accepted restored sending from the affected flow tools.

Administrative role and group ownership issues were resolved by assigning the appropriate AWS role or group inside AWS and verifying console access. In cases where SSO-level access was missing, AWS access was provisioned by assigning the AWS application to the user in the Okta portal. Requesters were routed to the Microsoft MyAccess portal for AWS role/admin requests (approvals tracked via Automation for Jira) and to the DevOps Service Portal for environment- or resource-specific work owned by Dev teams. Service account identities required for deployments were synchronized into the target AWS accounts and access was validated with the teams. QuickSight access was fulfilled through the internal self-service portal by requesting AWSQuickSightAuthor or AWSQuickSightReadOnly and awaiting approver action. When S3 buckets did not exist and tickets could not be transferred between ServiceDesk systems, requesters opened DevOps tickets; DevOps created the buckets and then granted the requested write access. When assigned roles produced no apparent permissions or environment visibility, users removed themselves from the group and re-requested membership so the role was reprovisioned, which restored console permissions, portal visibility, and credential creation. Production administrator removals and cleanups were performed by DevOps and access changes were verified after removal. One ticket recorded botocore GetRoleCredentials ForbiddenException and timeout connection errors from a home network versus the office; no configuration change was documented for that case in the ticket set.

Access for external providers was constrained to dedicated read-only replica hosts; direct network-level access to the DB master was prevented. Provider connectivity was routed through controlled paths (replica subnets and bastion/jump hosts or Tailscale endpoints) and auditing/monitoring was enabled using CloudTrail, Datadog, CloudWatch and Microsoft Sentinel to capture access and detect anomalies. This approach separated heavy consumer traffic onto replicas while preserving master protection.

The production ECS task was replaced with a new task instance to remove the CPU-constrained process. Starting the newer ECS task restored normal responsiveness for report and data requests and resolved the performance degradation in production.