#Lightning Aura Components3 discussing

Hi @Kushagra Rajput,

Your direction is right. Here is a simple way to build it.

1. Set up AWS SES first

• Verify your sender email or domain in SES.
• If your SES account is in sandbox mode, you can only send to verified emails, so request production access.
• Create an email template in SES. SendBulkEmail needs a template, even for a simple message.

2. Authentication from Salesforce

Use a

3. The API call

Send a POST request to /v2/email/outbound-bulk-emails (SES v2). One call accepts

4. Use Batch Apex

• Implement Database.Batchable<SObject> and Database.AllowsCallouts. Without AllowsCallouts, the callout fails.
• Run it with a scope of 50, so each execute makes one SES call.

apex

public class BulkEmailBatch implements Database.Batchable<SObject>, Database.AllowsCallouts {
    public Database.QueryLocator start(Database.BatchableContext bc) {
        return Database.getQueryLocator('SELECT Email FROM Contact WHERE Email != null');
    }
    public void execute(Database.BatchableContext bc, List<Contact> scope) {
        List<Object> entries = new List<Object>();
        for (Contact c : scope) {
            entries.add(new Map<String, Object>{
                'Destination' => new Map<String, Object>{ 'ToAddresses' => new List<String>{ c.Email } }
            });
        }
        Map<String, Object> body = new Map<String, Object>{
            'FromEmailAddress' => 'sender@yourdomain.com',
            'DefaultContent' => new Map<String, Object>{
                'Template' => new Map<String, Object>{ 'TemplateName' => 'YourTemplate', 'TemplateData' => '{}' }
            },
            'BulkEmailEntries' => entries
        };
        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:AWS_SES/v2/email/outbound-bulk-emails');
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json');
        req.setBody(JSON.serialize(body));
        HttpResponse res = new Http().send(req);
        // check res.getStatusCode() and log failures
    }
    public void finish(Database.BatchableContext bc) {}
}

Run it with Database.executeBatch(new BulkEmailBatch(), 50);

5. Things to remember

• Check the response for each entry (the API returns a status per email), and log failures.
• Respect your SES sending rate limit.
• Handle bounces and unsubscribes (SES configuration sets with SNS can help).

Hope this helps. Share where you get stuck and I can help further.

Hi Kushagra, 

Yes, creating an IAM user is the correct path, and it's confirmed by AWS's own official documentation, not just common practice. AWS explicitly recommends creating an IAM user with least-privilege permissions first, then generating access keys under that IAM user, never using your AWS root account credentials for this. 

Steps to get your Access Key and Secret Key (official AWS process): 

1. Log into the AWS Console with your root/admin account (only for this setup step, not for ongoing use). 

2. Go to IAM > Users > click "Create user". 

3. Give it a descriptive name, e.g. salesforce-s3-integration. 

4. Do NOT enable AWS Management Console access, this user only needs programmatic access, not console login. 

5. Attach a permission policy scoped only to what's needed, ideally a custom policy limited to s3:GetObject on your specific bucket/prefix, not full S3 access. This follows AWS's least-privilege guidance. 

6. After the user is created, go to that user > Security credentials tab > Access keys section > "Create access key". 

7. Select the use case (choose "Application running outside AWS" or similar, matching your Apex callout scenario). 

8. AWS shows you the Access Key ID and Secret Access Key ONCE. Download the CSV or copy both immediately, the Secret Access Key cannot be retrieved again after this screen, you'd have to delete and recreate the key if lost. 

Official reference:

Important note on "is this the only way": Technically no, AWS's own best-practice guidance actually recommends AGAINST long-term access keys where avoidable, and prefers IAM Roles with temporary/short-term credentials (via AWS STS) since those auto-expire and reduce risk if leaked. 

Official reference:

However, for a Salesforce Apex integration specifically, since Apex runs outside AWS and can't assume an IAM role directly the way an EC2/Lambda service can, using a scoped-down IAM user with long-term access keys (stored securely in Named Credential/Protected Custom Metadata, as I mentioned earlier) is the practical and accepted approach here. Just make sure to: 

- Scope the policy to only that one bucket/prefix 

- Rotate the access key periodically 

- Never commit it to code, always pull from Named Credential/Custom Metadata at runtime 

So to directly answer: yes, IAM user + access key is the right and standard way for your use case.