An Amazon Connect instance answers customer calls, stores recordings and transcripts in your own Amazon S3 buckets, and calls AWS Lambda functions with caller data in the middle of a flow, so its security sits across two control planes: the Connect admin website and AWS IAM. This guide explains the customer-side controls AWS documents for both: identity management choices, security profiles and their sensitive permissions, the service-linked role, Lambda resource policies, recording and transcript encryption with AWS KMS, encryption of sensitive customer input, CloudTrail logging, and controls that reduce misuse of outbound calling. It is written for contact centre engineers, AWS platform teams and security staff who own an Amazon Connect instance (AWS's administrator guide states that Amazon Connect Customer is the current name for the product previously called Amazon Connect). For voice channel fraud and caller manipulation, see the Voice AI Agent Security and Fraud Guide; this page stays with platform configuration.
This is an independent guide from NHI Mgmt Group, based on AWS's public documentation for Amazon Connect as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.
Key takeaways
- Pick identity management carefully, once. Users can live in Connect, in an existing directory or behind SAML 2.0 federation, and AWS documents that the choice cannot be changed after the instance is created.
- Guard the user editing permissions. Users - Create and Users - Edit let holders reset passwords and change identity details, so AWS advises keeping them to as few people as possible.
- Scope every Lambda invocation. Lambda resource policies should name
connect.amazonaws.comwith your source account and instance ARN, and functions receive caller data such as phone numbers. - Recordings live in your bucket under your KMS key. Recordings and chat transcripts delivered to S3 are protected by the KMS key set at instance creation, so bucket and key policies are your access boundary.
- Log UpdateUserIdentityInfo and friends. All public Connect APIs are recorded in CloudTrail; alert on identity, security profile, phone number and flow changes.
How identity and access work in Amazon Connect
There are two kinds of identity to manage. Connect users (agents, supervisors, administrators) sign in to the admin website and the Contact Control Panel (CCP) and are governed by security profiles. AWS principals (IAM users, roles and federated identities) manage the instance through the AWS console and APIs and are governed by IAM policies. Securing one without the other leaves a gap.
Identity management options
| Option (AWS docs) | How users sign in | Prerequisite | When to choose it |
|---|---|---|---|
| Store users within Amazon Connect | Connect-specific username and password | None | Small pilots and test instances |
| Link to an existing directory | Corporate credentials from Active Directory | Directory in AWS Directory Service, active in the same Region, prepared before instance creation | Organisations standardised on AWS Directory Service |
| SAML 2.0-based authentication | Through the link configured in your identity provider only | SAML configured before instance creation | Most production contact centres: MFA and conditional access come from your identity provider |
Because the option cannot be changed later (switching means deleting the instance and losing its configuration and metrics data), decide before you build. Our recommendation for production is SAML 2.0, so agent sign-in inherits your identity provider's MFA, session rules and leaver process. See the Identity Provider and SSO Security Guide.
Fine-grained access control
Beyond standard permissions, Amazon Connect supports tag-based, hierarchy-based and record-based access control in security profiles. AWS describes access control tags as an advanced feature under the shared responsibility model and advises understanding how granular configurations behave before applying them. Use them to keep regional or outsourced teams to their own queues, users and routing profiles, and test with a pilot profile first.
Admin roles and privileged access
A security profile is a set of permissions mapped to a contact centre role. AWS ships four defaults and recommends custom profiles that grant only what each user needs. New permissions are added regularly, so review profiles periodically.
| Default profile | Scope (AWS docs) | Guidance (ours) |
|---|---|---|
| Admin | Most actions in the instance | Two or three named people; federated sign-in with MFA; reviewed quarterly |
| CallCenterManager | User management, metrics and routing | Replace with a custom profile if managers do not need user editing |
| QualityAnalyst | Metrics | Add recording access only where evaluation needs it |
| Agent | Access to the CCP | Baseline; remove outbound calling where the role is inbound only |
Sensitive permissions
| Permission (API name) | Why it matters | Who should hold it |
|---|---|---|
Users - Create, Users - Edit (Users.Create, Users.Edit) | AWS notes holders can reset passwords, including an administrator's | As few people as possible |
Users - Edit permission (Users.EditPermission) | Assigns security profiles, including Admin | Admins only |
Security profiles - Create, Edit (SecurityProfiles.*) | Changes what every role can do | Admins only, under change control |
Call recordings (unredacted) - Access (CallRecordings.Unredacted.Access) | Full audio including any sensitive detail | Named quality and compliance staff; prefer the redacted permission |
Phone numbers - Claim, Edit, Release (PhoneNumbers.*) | Controls which flows numbers reach | Telephony engineers |
Flows - Edit, Publish (ContactFlows.Edit, ContactFlows.Publish) | Flows route calls and invoke Lambda functions | Flow developers, with peer review before publish |
Make outbound calls (OutboundCallAccess) | Places calls billed to your instance | Only roles that need outbound calling |
Watch for inherited permissions: AWS gives the example that editing users also grants listing all security profiles, because the editor needs the drop-down. AWS also notes that hiding the recording download icon is not a security control, since recordings can be retrieved by other means, so track who accesses recordings rather than relying on the icon. See the SaaS Admin Account Protection guide.
AWS-side privileged access
Anyone with broad connect:* IAM permissions in the account can change the instance outside the admin website. Keep Connect administration in a dedicated account or tightly scoped roles, use federated access through IAM Identity Center, and apply service control policies where your organisation uses them. See the AWS IAM Policies and Roles Guide.
Integrations, API tokens and service accounts
The service-linked role
Amazon Connect uses a service-linked role named AWSServiceRoleForAmazonConnect_unique-id, trusted by connect.amazonaws.com and governed by the AWS managed policy AmazonConnectServiceLinkedRolePolicy. It is created with the instance and lets Connect act on your behalf, including reading and deleting objects in the recordings bucket and writing flow logs to CloudWatch Logs. Feature-specific permissions (for example data streaming, Voice ID and outbound campaigns) are added as inline policies when you enable those features. AWS documents that the service-linked role is required for the updated admin website and for CloudTrail support. Restrict who can create, edit or delete service-linked roles in IAM.
Lambda functions
- Same Region: adding a function under Flows > AWS Lambda > Add Lambda Function adds the resource-based permission automatically.
- Cross-account or cross-Region: add the permission yourself with principal
connect.amazonaws.com, the source account that owns the instance and the instance ARN as source ARN, so only your instance can invoke the function. - Data minimisation: every invocation includes
Details.ContactDatawith the customer endpoint (phone number) and contact attributes. Log only what you need and give each function's execution role access to just the resources it uses (our recommendation). - Response handling: use STRING_MAP validation where a flat response is enough; it restricts values to alphanumeric, dash and underscore characters. Timeouts are capped at 8 seconds per invoke and 20 seconds for chained functions, and failures route to the Error branch, so design a safe fallback path.
- Secrets: functions that call CRMs or payment systems should read credentials from a secrets manager, never from contact attributes or environment variables in plain text (our recommendation).
See the AWS Lambda Security Guide and the AWS Secrets Manager guide.
Encrypting sensitive customer input
For values such as card numbers collected in a flow, Amazon Connect can encrypt data captured in the Stored customer input attribute with your public key. You upload the public key in .pem format and provide an X.509 certificate signed to prove possession of the private key; up to two keys can be active at once to support rotation. Decryption happens on your side with the AWS Encryption SDK, so the private key never needs to sit in Connect. Keep that private key in a hardware-backed or managed key store.
Recording and transcript encryption
| Data | Protection (AWS docs) | Customer action |
|---|---|---|
| Contact PII and content held by Connect | Encrypted with AWS owned KMS keys; data keys not shared across instances | None required |
| Call recordings and chat transcripts in your S3 bucket | S3 server-side encryption with the KMS key configured at instance creation | Use a customer managed key; restrict key and bucket policies; set S3 lifecycle to your retention policy |
| Customer Profiles | Customer managed KMS key required at domain creation | Own and monitor the key; grants are created for the service |
| Voice ID | Customer managed key required; changing it re-encrypts existing data | Monitor grants in CloudTrail |
| Outbound campaigns, agent assist, AppIntegrations | Optional customer managed key | Use your key where your data policy requires it |
Recordings pass through two phases: held within Connect during and after the contact, then delivered to your bucket. Once there, the bucket policy, the KMS key policy and IAM decide who can read them. Our recommendations: block public access on the bucket, allow reads only to the service-linked role and a small set of named roles, require the KMS key for every read, and keep the bucket in a dedicated account where possible. AWS notes that revoking a service's access to a key stops it decrypting data, which can break workflows, so change key policies under change control. See the AWS KMS Security Guide.
Logging and detection
All public Amazon Connect APIs are recorded in AWS CloudTrail, including the requester's identity and source IP. Without a trail, the CloudTrail console shows recent events in Event history; create an organisation or multi-Region trail to keep them. Voice ID events use their own event source and redact fields that might hold PII. KMS requests made by Connect features also appear in CloudTrail, which lets you see when recordings are decrypted. See the AWS CloudTrail Guide.
| Event or signal | Why alert |
|---|---|
UpdateUserIdentityInfo | AWS warns a changed email address followed by a password reset can take over an account |
| Security profile changes and assignments | Privilege growth, especially Admin or Users - Edit permission |
| Phone number claim, release or flow association changes | Can redirect customer calls |
| Flow publish and Lambda association changes | Alters routing and the data sent to functions |
| Instance storage configuration changes | Could move recordings to another bucket or key |
| KMS Decrypt calls on the recordings key | Shows who is reading recordings |
| Unusual outbound call volume or destinations (contact records) | Early sign of misuse of outbound calling |
Flow logs written to CloudWatch Logs help trace what a flow did for a given contact. Keep them for investigation, but treat them as sensitive because they may contain contact attributes.
Metrics that show it is working:
- Users holding Admin, Users - Edit or Users - Edit permission (trend down).
- Share of Lambda permissions scoped with source account and source ARN (target 100%).
- Users with unredacted recording access, reviewed each quarter.
- Days of CloudTrail history retained centrally.
- Agents with outbound calling who do not use it in 90 days.
Hardening baseline
A phased rollout. Permission changes to security profiles can be reverted by editing the profile, so pilot each one on a small group first.
- Decide identity management before creating production instances; prefer SAML 2.0.
- Turn on logging: organisation or multi-Region CloudTrail trail, flow logs where needed, CloudTrail Lake or SIEM forwarding.
- Set up storage: customer managed KMS key, private bucket with Block Public Access, lifecycle rules, and least-privilege bucket and key policies.
- Build custom security profiles per role, and limit Admin, Users - Create, Users - Edit and Users - Edit permission.
- Restrict recordings: redacted access as the default; unredacted for named staff.
- Review Lambda functions: scope resource policies, minimise logging of caller data, move credentials into a secrets manager.
- Encrypt sensitive input collected in flows with your public key.
- Limit outbound calling: remove Make outbound calls from inbound-only profiles, set a valid outbound caller ID and follow AWS outbound calling restrictions.
- Add fine-grained access control with tags or hierarchies for regional or outsourced teams, after a pilot.
- Schedule reviews: quarterly security profile and Lambda reviews, and a yearly key policy review (our recommendations).
Reducing misuse of outbound calling
Outbound calls cost money and carry your caller ID, so treat outbound capability as a privilege. AWS documents that outbound calls using UIFN numbers are blocked, that a valid outbound caller ID should be configured, and that calls to China need approval with strict use criteria, with service suspended for restricted use. Our additional recommendations: grant Make outbound calls only to profiles that need it, alert on spikes in outbound contact records or calls to unexpected countries, and review AWS service quotas for your instance. See the Contact Centre Fraud Prevention buyer's guide and the VoIP and SIP Security Guide.
| Organisation profile | Priority choices |
|---|---|
| Single team, one instance | SAML 2.0, custom profiles, scoped Lambda policies, CloudTrail trail, private recordings bucket |
| Multi-region or outsourced | All of the above plus tag or hierarchy access control, separate accounts per environment, central log account |
| Regulated (payments, health) | Customer managed keys throughout, encrypted Stored customer input, redacted recording access by default, documented key procedures |
Common misconfigurations
- Users - Edit given to supervisors by default: this permission can reset passwords. Use a custom profile without it.
- Lambda permission without source ARN: add source account and instance ARN so only your instance can invoke the function.
- Treating the download icon as access control: track recording access through permissions, bucket policy and KMS logs instead.
- Recordings bucket shared with other data: keep a dedicated bucket and key with narrow policies.
- Identity option chosen for a pilot carried into production: plan SAML 2.0 before building, since the choice is fixed.
- Every agent able to dial out: remove Make outbound calls from inbound-only roles.
Apply AWS service updates and review the AWS security bulletins page as part of routine operations.
Framework mapping
| Amazon Connect control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique it helps address |
|---|---|---|---|
| SAML 2.0 federation, limited Users - Edit | IA-2, AC-2 | PR.AA-03 | T1078.004 Cloud Accounts |
| Custom security profiles, fine-grained access | AC-6 | PR.AA-05 | T1098 Account Manipulation |
| Lambda resource policies, secrets in a vault | AC-6, IA-5 | PR.AA-01 | T1528 Steal Application Access Token |
| KMS keys, private recordings bucket | SC-12, SC-28 | PR.DS-01 | T1530 Data from Cloud Storage |
| CloudTrail and flow logs | AU-6 | DE.CM-03, PR.PS-04 | T1098 Account Manipulation |
Practitioner checklist
- Identity management option chosen deliberately; SAML 2.0 for production.
- Admin, Users - Create, Users - Edit and Users - Edit permission held by named people only.
- Custom security profiles per role; default profiles reviewed after AWS adds permissions.
- Unredacted recording access limited and reviewed quarterly.
- Recordings bucket private, encrypted with a customer managed key, with lifecycle rules.
- Every Lambda permission scoped to source account and instance ARN; caller data logging minimised.
- Sensitive flow input encrypted with your public key; private key held in a managed store.
- CloudTrail trail in place with alerts on UpdateUserIdentityInfo, profile, number, flow and storage changes.
- Make outbound calls limited to roles that need it; outbound volume monitored.
- IAM access to
connect:*restricted to a small set of roles.
Standards and references
- AWS: Security profiles in Amazon Connect
- AWS: Best practices for security profiles
- AWS: Plan identity management in Amazon Connect
- AWS: Service-linked roles for Amazon Connect
- AWS: Grant Amazon Connect access to Lambda functions
- AWS: Encryption at rest in Amazon Connect
- AWS: Encrypt customer input
- AWS: Logging Amazon Connect API calls with CloudTrail
Related NHI Mgmt Group resources: Voice AI Agent Security and Fraud Guide, Caller Authentication in Contact Centres, AWS Security Guide, AWS KMS Security Guide.