Cloud / Amazon Chime Interview questions

Amazon Chime was an AWS-managed communications service for online meetings, video conferencing, chat, and business calling. Users reached it through desktop, web, and mobile clients, while admins managed accounts and users from a separate console.

AWS stopped accepting new customers on February 19, 2025, and ended support for the service, including Business Calling, on February 20, 2026. A group of customers who received an extension kept meeting access until September 8, 2026.

The developer product, the Amazon Chime SDK, was not part of that shutdown. When an interviewer says "Chime" today, they usually mean the SDK.

The Amazon Chime SDK is a set of APIs and client libraries that lets developers add real-time voice, video, and messaging to their own applications. AWS runs the media infrastructure; you build the user interface and the business logic around it.

It covers five areas: meetings, messaging, identity, media pipelines, and voice (SIP trunking and programmable calls). You can use one area or combine several.

The SDK works independently of any Amazon Chime administrator account. All you need is an AWS account and IAM permissions to call the APIs.

The Chime SDK is split into five API areas, each with its own namespace in the AWS SDKs.

Most real applications mix two or three areas. A telehealth app may use only Meetings and Media pipelines, while a support portal might combine Messaging and Identity for chat with Voice for phone calls. Because each area has its own API namespace, you can also grant IAM permissions per area.

AWS ships client libraries for JavaScript (browsers), iOS (Swift), Android (Kotlin and Java), and React Native. They handle the WebRTC work: device selection, audio and video transport, reconnection, and metrics.

On top of the JavaScript library sits the Chime SDK React component library, which gives you ready-made pieces such as a video tile grid, roster, and device selectors. It saves time when you do not want to build every control from scratch.

Each client library needs the meeting and attendee details returned by your backend, since the SDK does not hand out join URLs on its own.

An SDK meeting is a real-time media session that your server creates with the CreateMeeting API. It is pinned to one AWS media region and identified by a MeetingId, plus an optional ExternalMeetingId that maps back to your own data.

The response also carries a MediaPlacement block with the endpoints clients connect to. Attendees then join from client libraries using their own tokens.

Note that the SDK does not create meeting codes or join URLs for end users. Your application decides how people find and enter a meeting. DeleteMeeting ends it for everyone.

An attendee is a participant record created for one person (or device) in one meeting through CreateAttendee. The response includes an AttendeeId, your ExternalUserId, the Capabilities, and a JoinToken.

ExternalUserId is how you tie the attendee to a user in your own system, for example a patient or an agent ID. AttendeeId is assigned by Chime.

You can create attendees one at a time, or in bulk with BatchCreateAttendee (up to 100 per call) and CreateMeetingWithAttendees (up to 10).

The JoinToken authorizes one attendee to connect to one meeting's media session. It comes back in the CreateAttendee response and is passed to the client library, which presents it when it opens the connection.

Think of it as a bearer credential for that attendee. Anyone who holds it can join as that person, so deliver it only over your authenticated channel and never log it.

It does not grant AWS API access. Calls such as CreateMeeting still require IAM credentials on your backend.

MediaPlacement is a block in the CreateMeeting response that lists the service endpoints clients use to connect. The main fields are AudioHostUrl, AudioFallbackUrl, SignalingUrl, TurnControlUrl, and screen-related URLs such as ScreenDataUrl.

The client library uses SignalingUrl for session negotiation and TurnControlUrl to fetch TURN credentials when a direct media path is not possible.

You never edit these values. Pass the whole Meeting object to the client unchanged, because the library builds its configuration from it.

MediaRegion tells Chime which AWS Region should host the meeting's media services. Every attendee, wherever they are, connects to that one region for the life of the meeting.

Pick a region close to most attendees, since distance drives latency and audio quality. It is set when you call CreateMeeting and cannot be changed afterward.

If you leave it out, Chime chooses a region for you, which may not match where your users actually are.

Region choice also matters for data residency. If a policy says European callers must stay on European infrastructure, set a European media region explicitly instead of relying on the default.

Amazon Voice Focus is AWS's machine-learning noise suppression for Chime SDK audio. It filters non-speech sounds such as keyboard clicks, fans, or barking dogs so the voice stands out.

It runs on the client side, in the attendee's browser or app, before audio is sent. Your application exposes a toggle if you want users to control it.

Do not confuse it with echo reduction, which is a separate meeting feature requested at meeting creation and billed as an add-on.

A standard session supports up to 250 attendees, and a high-definition session supports up to 100. Beyond that you need replica meetings for view-only audiences.

On the video side, a meeting allows 25 concurrent video streams, and an attendee can subscribe to 25 at once.

Some quotas are adjustable through Service Quotas and others are fixed, so check the endpoints and quotas page before capacity planning.

Content sharing is screen, window, or tab sharing during a meeting. The presenter's share travels as its own stream, separate from their camera.

It shows up in the roster as a distinct attendee whose ID is the presenter's AttendeeId followed by #content. This lets the UI render it in a different layout from the camera tiles.

In the JavaScript library you start it with calls such as startContentShareFromScreenCapture. The maximum quality is capped by the Content.MaxResolution meeting feature.

Data messages let attendees send small payloads to each other through the meeting's existing connection. You send one with realtimeSendDataMessage(topic, data, lifetimeMs) and listen with realtimeSubscribeToReceiveDataMessage(topic, callback).

Payloads are limited to about 2 KB, so they suit lightweight signals: raised hands, emoji reactions, poll votes, or whiteboard pointer positions.

They are not a chat history or file transfer system. For persistent conversations, use the Messaging API instead.

Receivers subscribe by topic, so one meeting can carry several independent streams of signals, such as one topic for reactions and another for whiteboard updates. Most teams send small, compact JSON. Do not rely on data messages to rebuild state for someone who joins late; keep the authoritative state in your own backend.

Chime SDK Messaging is a managed service for persistent chat. Conversations live in channels; users join through channel memberships and exchange channel messages.

Every call is made on behalf of an identity. You pass the ARN of an AppInstanceUser in the x-amz-chime-bearer header, called the ChimeBearer, so the service knows who is acting.

Messages reach connected clients in real time over a WebSocket session, and you can also stream them to other AWS services.

Moderation is built in too: channel moderators can ban users or redact messages, and channel flows can screen messages before delivery. Persistence is set per message, so the same service can back durable team chat and short-lived control signals.

An AppInstance is the top-level container for identity and messaging resources. Under it you create AppInstanceUsers, bots, admins, and channels.

Most teams create one AppInstance per application environment, such as dev, staging, and production, so users and channels never mix across them.

An AppInstanceUser is your app's representation of a person. Its ARN is the value used as the ChimeBearer in Messaging calls.

AppInstances are also where admins are defined, since an AppInstanceAdmin can manage every channel inside it. Message retention settings can be applied at the AppInstance level, which gives you one place to enforce a retention policy.

A Voice Connector is a managed SIP trunking service. It links your PBX, session border controller, or contact center to AWS and the public telephone network.

It supports origination (calls from the phone network to your system) and termination (calls from your system out to the phone network). You secure it with an allowed IP list and/or SIP credentials, and it supports TLS and SRTP encryption.

Voice Connector Groups chain several connectors in priority order for failover, and media can be streamed to Kinesis Video Streams for analysis.

A SIP media application (SMA) is programmable voice. When a call arrives, Chime invokes your AWS Lambda function with an event describing the call, and your function replies with a list of actions such as Speak, PlayAudio, or CallAndBridge.

This lets you build IVR menus, call routing, voicemail, or bot-driven calls entirely in code, without running telephony servers.

An SMA is attached to a phone number or Voice Connector hostname through a SIP rule.

Because the logic is a Lambda function, you can read from DynamoDB or call internal APIs mid-call, for example to look up a caller's account before deciding where to route. SMAs can also place outbound calls and join a caller into an SDK meeting.

Media pipelines are managed workflows that process audio and video from meetings or calls without you running media servers.

The main types are:

1. Media capture - records meeting media to Amazon S3.
2. Media concatenation - stitches captured chunks into continuous files.
3. Live connector - streams a meeting to an RTMP destination.
4. Media stream / insights - sends media to Kinesis Video Streams and services such as Amazon Transcribe for analysis.

You create and delete pipelines with the media pipelines API, usually from your backend.

A media capture pipeline records the audio, video, and screen share of a Chime SDK meeting and writes the output to an Amazon S3 bucket. You start it with CreateMediaCapturePipeline, using the meeting as the source (ChimeSdkMeeting) and a bucket as the sink.

The bucket policy must allow the Chime media pipelines service principal to write, otherwise the pipeline fails.

Output arrives as chunked files. If you want one continuous recording per stream, feed them into a concatenation pipeline afterward.

The meeting readiness checker is a utility in the JavaScript client library (DefaultMeetingReadinessChecker) that tests whether a user's setup can handle a meeting before they join.

It can check the selected microphone, speaker, and camera, camera resolutions, content-share ability, and network connectivity over both UDP and TCP.

It is typically used to build a "check your setup" screen so that problems like a blocked network or a missing mic permission show up before the call starts.

Each check returns a result you can map to a friendly message, such as "your camera is blocked" or "your network is blocking UDP". It runs in seconds, so it fits in a pre-join lobby and cuts support tickets caused by predictable local problems.

The Chime SDK uses pay-as-you-go pricing. Meetings are billed by attendee-minutes, so you only pay while attendees are actually connected. There is no per-user license and no upfront commitment.

Extra features such as echo reduction and high-definition sessions are priced separately, and other components like media pipelines or Voice Connectors have their own meters.

Always confirm current rates on the Chime SDK pricing page, since rates change.

To estimate cost, multiply expected attendees by average minutes per meeting by meetings per month, then add the separate meters for features such as echo reduction or HD. Capping Attendee.MaxCount helps stop a runaway session from inflating the bill.

The Amazon Chime service was a finished end-user product for meetings, chat, and calling. The Chime SDK is a developer toolkit for embedding similar capabilities into your own app.

The two are independent: an SDK meeting never appeared inside the Chime app.

Joining always involves your backend, because only it holds the AWS credentials needed to create meeting resources.

1. The user opens your app and asks to join a session.
2. Your backend authenticates the user and calls CreateMeeting (or reuses an existing meeting).
3. It calls CreateAttendee for that user.
4. It returns the Meeting and Attendee objects to the client.
5. The client builds a MeetingSessionConfiguration and starts the session; media then flows directly between the client and the Chime media service.

sequenceDiagram
  participant C as Client app
  participant B as Your backend
  participant S as Chime SDK API
  participant M as Chime media service
  C->>B: Request to join (authenticated)
  B->>S: CreateMeeting
  S-->>B: Meeting (MediaPlacement, MediaRegion)
  B->>S: CreateAttendee
  S-->>B: Attendee (JoinToken)
  B-->>C: Meeting + Attendee
  C->>M: Connect with JoinToken
  M-->>C: Audio, video, content streams

The backend is never in the media path, which is why meeting traffic does not load your servers.

Because CreateMeeting and CreateAttendee are IAM-authorized AWS API calls, and embedding access keys in a browser or mobile app would expose them to everyone.

A server also gives you control. You can check that the user is allowed in, choose the media region, set an ExternalMeetingId for your own records, make the call idempotent with ClientRequestToken, and attach notification settings or meeting features.

const { ChimeSDKMeetingsClient, CreateMeetingCommand,
        CreateAttendeeCommand } = require('@aws-sdk/client-chime-sdk-meetings');

const client = new ChimeSDKMeetingsClient({ region: 'us-east-1' });
const { Meeting } = await client.send(new CreateMeetingCommand({
  ClientRequestToken: requestId,
  MediaRegion: 'us-east-1',
  ExternalMeetingId: 'room-42'
}));
const { Attendee } = await client.send(new CreateAttendeeCommand({
  MeetingId: Meeting.MeetingId,
  ExternalUserId: 'user-17'
}));

Return only Meeting and Attendee to the client, never the credentials behind them.

After receiving the meeting and attendee from your backend, you build a session, select devices, attach UI elements, and call start().

const logger = new ConsoleLogger('chime', LogLevel.INFO);
const deviceController = new DefaultDeviceController(logger);
const config = new MeetingSessionConfiguration(meeting, attendee);
const session = new DefaultMeetingSession(config, logger, deviceController);
const av = session.audioVideo;

const mics = await av.listAudioInputDevices();
await av.startAudioInput(mics[0].deviceId);
av.bindAudioElement(document.getElementById('meeting-audio'));
av.addObserver({
  videoTileDidUpdate: (tile) => { /* bind tile to a video element */ }
});
av.start();
av.startLocalVideoTile();

Order matters: devices and the audio element should be ready before start(), and browsers expect the call to follow a user gesture because of autoplay rules. In older library versions the device call is named chooseAudioInputDevice.

The SDK does not choose for you; you decide at CreateMeeting time. The usual approach is to let the first joining client measure which region is nearest and report it to your backend.

AWS publishes a lookup endpoint, https://nearest-media-region.l.chime.aws, that returns the closest media region for the caller. The client calls it, sends the result to your server, and the server passes it as MediaRegion.

For groups spread across continents, you may prefer a region near the majority of attendees, since everyone connects to the same one. Once the meeting exists, the region cannot be changed.

If attendees are known in advance, you can also decide the region from account data, such as the host's office location, which avoids waiting for a client probe. Log the chosen region with your session record so quality complaints can be compared against distance.

The JavaScript library tries to reconnect automatically. By default it keeps trying for about two minutes, which is controlled by the reconnect timeout in MeetingSessionConfiguration.

During that window the client reports progress through observer callbacks, for example audioVideoDidStartConnecting(reconnecting) and connectionDidBecomePoor. If it succeeds, audio and video resume without a new join.

If the attendee never reconnects, the session stops with a status code from MeetingSessionStatusCode, and the service emits an AttendeeDropped event on the server side. Your UI should handle both so users see a clear "reconnecting" or "rejoin" prompt.

You can tune this. The reconnect timeout is configurable, and a connection health policy controls how quickly the library flags poor connectivity or suggests turning off video. Show a clear banner during reconnecting, since silent audio is a common reason users abandon calls.

A standard session is the default and supports up to 250 attendees with video up to 720p. A high-definition session is created when you request FHD (1080p) video through Video.MaxResolution, and it supports fewer attendees.

Choose HD only when picture quality is the product, such as remote inspections or telemedicine. For large calls, standard is cheaper and holds more people.

The HD setting is a ceiling, not a requirement: clients can still send lower resolutions inside an HD session. Request FHD only when your cameras and your users' bandwidth can actually benefit.

Meeting features are options you pass in MeetingFeatures when calling CreateMeeting. They change what the session allows and sometimes what it costs.

• Audio.EchoReduction - set to AVAILABLE when attendees often use speakerphones or shared rooms. It is supported in the JavaScript and React libraries and carries an extra charge.
• Video.MaxResolution - cap or disable webcam video, for example None for audio-only apps.
• Content.MaxResolution - control screen-share quality.
• Attendee.MaxCount - cap the meeting size below the service limit.

Lowering limits is also a cost and abuse guardrail: a webinar that only needs 30 people should not allow 250.

Features are fixed when the meeting is created, so decide them in your backend based on the type of session, for example a webinar versus a one-to-one consult, rather than leaving the choice to clients.

Capabilities control what each attendee can do with audio, video, and content. Each is set to one of SendReceive, Send, Receive, or None.

You set them in CreateAttendee and change them later with UpdateAttendeeCapabilities (or the batch variants, including a call that updates everyone except named attendees).

This enables roles. A viewer in a webinar gets Receive for audio and video, a presenter gets SendReceive, and a moderator can be muted or have video removed mid-call by changing capabilities. Because the change is enforced by the service, a modified client cannot bypass it.

A single meeting stops at 250 attendees (100 in HD), so large events use replica meetings. You create a primary meeting for presenters, then create replica meetings that mirror its audio and video for the audience.

You do this by calling CreateMeeting with the PrimaryMeetingId of the main meeting. Each replica has its own attendee cap, so the audience is spread across replicas while the presenters stay in one place. By default a primary meeting can have 4 replicas, and that quota is adjustable.

Replica attendees are typically receive-only, which fits webinars, town halls, and live classes. If every participant needs to talk, replicas are the wrong tool, and you should redesign around smaller rooms.

Plan the audience experience as well. Create audience attendees against the replica meeting, and keep send capabilities off for them so that viewers cannot publish audio or video into the event.

You enable it from your backend with StartMeetingTranscription, passing a TranscriptionConfiguration. The configuration selects the engine, either Amazon Transcribe or Amazon Transcribe Medical, plus a language code and optional settings.

Chime streams meeting audio to the engine. Results come back to clients as transcript events, which the JavaScript library exposes through the transcription controller, including partial and final results for live captions.

The service uses a service-linked role to call Transcribe on your behalf. You stop it with StopMeetingTranscription. If you also need a stored transcript, save the final events yourself or use a media insights pipeline.

Language and engine settings matter. Pick the language code your speakers actually use, and consider custom vocabulary or content redaction in the engine settings if your domain has unusual terms or sensitive data. Treat captions as best-effort and let users switch them off.

You record with a media capture pipeline. Your backend calls CreateMediaCapturePipeline with the meeting ARN as the source and an S3 bucket as the sink, then stops it with DeleteMediaCapturePipeline when the meeting ends.

The artifacts configuration decides what you get: audio, video, content share, and optionally a composited video that blends participants into one grid. Output lands in S3 as chunked files.

To turn chunks into continuous files, start a media concatenation pipeline afterward.

flowchart LR
  A["Meeting running"] --> B["Backend: CreateMediaCapturePipeline"]
  B --> C["Chunked artifacts in S3"]
  C --> D["Backend: CreateMediaConcatenationPipeline"]
  D --> E["Continuous recording files in S3"]
  A --> F["Backend: DeleteMediaCapturePipeline at meeting end"]

Tell attendees they are being recorded in your UI; the SDK does not do this for you.

All three work on meeting media, but they solve different jobs.

Capture and concatenation are about storage, usually run in sequence. The live connector is about broadcast, for example sending a webinar to a streaming platform that accepts RTMP.

They are independent, so you can run capture and live connector on the same meeting at once.

Pick by timing. If you need a playback file tomorrow, use capture, then concatenation. If you need viewers right now on another platform, use the live connector. Start either one once attendees are present so you do not record or broadcast an empty room.

The Chime SDK publishes meeting lifecycle events so your backend can react without polling. Two delivery routes exist.

1. Amazon EventBridge - events arrive with source aws.chime and detail type "Chime Meeting State Change". Add a rule to route them to Lambda, SQS, or other targets.
2. SNS or SQS - pass a notification configuration when calling CreateMeeting.

Typical event types include chime:MeetingStarted, chime:MeetingEnded, chime:AttendeeJoined, chime:AttendeeLeft, and chime:AttendeeDropped.

Common uses are stopping a recording when the meeting ends, writing attendance records, and alerting on drops.

Prefer EventBridge for new designs because one rule can filter by event type and fan out to several targets. Make handlers idempotent, since events can be delivered more than once and may arrive out of order.

An empty meeting does not live forever. For a non-replica meeting, if no attendees connect for 5 continuous minutes, the service ends it automatically and emits a chime:MeetingEnded event.

After that, calls that reference the meeting, including GetMeeting and CreateAttendee, return a not-found error. Any attendee object or JoinToken you handed out earlier becomes useless.

The practical rule: create meetings close to when people need them, and handle the not-found case by creating a fresh meeting. Using the same ExternalMeetingId in your own database makes it easy to map the old and new meeting to one logical session.

A video tile is the SDK's handle for one incoming or outgoing video stream. You do not attach streams directly; you listen for tile changes and bind each tile to a <video> element.

1. Add an observer with videoTileDidUpdate(tileState).
2. Read tileState.tileId, boundAttendeeId, localTile, and isContent.
3. Call audioVideo.bindVideoElement(tileId, element).
4. Free the element in videoTileWasRemoved.

Your own camera is a local tile, started with startLocalVideoTile(). Because attendees can receive at most 25 streams, large calls use a priority-based downlink policy (VideoPriorityBasedPolicy) to choose which remote videos to show and at what quality.

A common bug is leaving a tile bound after an attendee leaves, which freezes the last frame. Unbind or hide the element inside videoTileWasRemoved, and rebuild your layout whenever the tile count changes.

Both are video frame processors that run on the client, so no extra server work is needed. A machine-learning segmentation model separates the person from the background in each frame, then the processor either blurs the rest or swaps it for an image.

In the JavaScript library you create a BackgroundBlurVideoFrameProcessor or BackgroundReplacementVideoFrameProcessor, wrap it in a DefaultVideoTransformDevice with the camera's device ID, and start that device as your video input.

Check support first, for example with the processor's isSupported() method, because older or low-powered devices may struggle. Expect higher CPU use while the effect is on.

Replacement needs an image supplied as a blob, which you can load from your own storage. Reuse one processor across toggles where possible, since loading the model is the costly part, and call destroy() when the user leaves.

Work from the browser outward, since most no-audio cases are client-side.

On the server side, CloudWatch metrics such as AttendeeAudioDrops and AttendeeAuthorizationErrors point to drops or token problems. Also confirm the same attendee is not joined from a second device, which can disconnect the first.

A ThrottledClientException (HTTP 429) means your backend exceeded the API rate for a Chime SDK endpoint. Before asking for higher limits, look for bugs that burn through calls, such as creating meetings in a loop or never cleaning them up.

1. Replace separate CreateMeeting and CreateAttendee calls with CreateMeetingWithAttendees (up to 10 attendees) or BatchCreateAttendee (up to 100).
2. Pre-create attendees and hand them out as invitees arrive.
3. Retry with exponential backoff and jitter.
4. Delete meetings you no longer need.
5. Only then request a quota increase, for those quotas marked adjustable.

Note that some rates are fixed, so batching and design changes are often the only fix.

Clients open a WebSocket connection to the messaging endpoint and receive messages as they arrive. The connection is represented by a DefaultMessagingSession in the JavaScript library.

1. Call GetMessagingSessionEndpoint to get the WebSocket endpoint.
2. Build a MessagingSessionConfiguration with the user's AppInstanceUser ARN, a session ID, and the endpoint.
3. Add an observer such as messagingSessionDidReceiveMessage.
4. Call start().

Sending still uses the REST API (SendChannelMessage) with the ChimeBearer header. Messages are stored per channel according to their persistence setting, and you can also stream messaging data out to Kinesis or EventBridge for analytics and archiving.

The WebSocket only delivers what arrives while the client is connected. After a reconnect, or when a user opens a channel, fetch missed messages with ListChannelMessages. Pair live delivery with a history load so the screen is never missing anything.

A channel flow runs your AWS Lambda processors on messages before they are delivered to a channel. It is the hook for filtering, redaction, or enrichment.

You create a flow with CreateChannelFlow, listing up to three processors in execution order, each with a FallbackAction of CONTINUE or ABORT if the Lambda fails. Then you attach it to a channel with AssociateChannelFlow.

When a user sends a message, it is held pending. Each processor receives it, and when it finishes it calls ChannelFlowCallback to return the (possibly changed) message or to deny it. Only then is it delivered.

Typical uses are profanity filtering, redacting card numbers or personal data, and translating text.

Keep processors fast. The message stays pending while the Lambda functions run, so a slow processor delays delivery for everyone in the channel. Choose fallback actions deliberately: ABORT for compliance filters that must never be skipped, CONTINUE for optional enrichment.

Channel privacy decides who can find and join a channel.

Separately, the mode setting (UNRESTRICTED or RESTRICTED) controls whether regular members can list other members. Channel moderators can also ban users or delete messages regardless of privacy.

Pick privacy first, then set the mode. For a support product, a customer's chat with an agent should be private and restricted, while an internal announcements room can be public and unrestricted. Admins and moderators can remove members from either type.

A SIP rule maps an incoming call trigger to a SIP media application. When a call matches, Chime invokes the target application's Lambda function.

A rule has a trigger type, a trigger value, and one or more targets:

• ToPhoneNumber - the dialed E.164 number, for example a number you provisioned.
• RequestUriHostname - the hostname on a Voice Connector, for calls arriving over SIP trunking.

Each rule lists target applications with a priority, so you can add a second region as failover.

flowchart TD
  A["Incoming call"] --> B{SIP rule match?}
  B -- ToPhoneNumber --> C["Dialed number matches rule"]
  B -- RequestUriHostname --> D["Voice Connector hostname matches rule"]
  C --> E["Target SIP media application"]
  D --> E
  E --> F["Chime invokes Lambda with call event"]
  B -- No match --> G["Call rejected"]

A trigger value can belong to only one rule, which keeps routing unambiguous.

Control follows a request-response loop. Chime sends your Lambda an invocation event describing what just happened, and your Lambda answers with actions to perform next.

Events include NEW_INBOUND_CALL, RINGING, CALL_ANSWERED, ACTION_SUCCESSFUL, ACTION_FAILED, and HANGUP. Actions include Speak, PlayAudio, SpeakAndGetDigits, CallAndBridge, RecordAudio, and Hangup.

{
  "SchemaVersion": "1.0",
  "Actions": [
    {
      "Type": "Speak",
      "Parameters": {
        "Text": "Welcome. Please hold while we connect you.",
        "Engine": "neural",
        "LanguageCode": "en-US",
        "VoiceId": "Joanna"
      }
    }
  ]
}

After each action finishes, Chime invokes the Lambda again with ACTION_SUCCESSFUL or ACTION_FAILED, so your code works as a simple state machine. Always handle failures and HANGUP so calls end cleanly.

Chime also passes TransactionAttributes back to you on each invocation, so a multi-step menu can keep simple state, such as the digits entered so far, without an external store.

Choose a Voice Connector when you simply need to connect existing telephony to the phone network, and a SIP media application when you need code to decide what a call does.

They also combine well. A Voice Connector can carry calls from your PBX, and a SIP rule on its hostname can send some of them to an SMA for automated handling before they reach an agent.

Security sits in three layers: who can call the APIs, who can join, and who can read the output.

1. API access - give your backend role least-privilege IAM permissions for just the calls it needs, such as chime:CreateMeeting and chime:CreateAttendee. Never ship AWS credentials to clients.
2. Joining - authenticate the user in your app before creating an attendee, treat JoinTokens as secrets, and use attendee capabilities to limit what each person can send.
3. Data in motion - meeting signaling and media are encrypted in transit.
4. Stored output - lock down S3 buckets used for recordings with a restrictive policy and KMS encryption.
5. Network and audit - use interface VPC endpoints (AWS PrivateLink) where available and review API activity in CloudTrail.

For regulated data, confirm HIPAA eligibility and sign the AWS BAA before handling protected health information.

Choose the Chime SDK when the call is part of your product and you need control over experience, data, and integration. Choose an off-the-shelf tool when people only need to meet and you do not want to maintain a UI.

The trade-off is effort: with the SDK you build roster, permissions, layout, and error handling yourself. If your use case is a standard internal meeting, that work rarely pays off.

The Amazon Chime service reached end of support on February 20, 2026, and customers with extensions ran until September 8, 2026. At this point, any remaining use means migrating, not planning to migrate.

1. Inventory - list users, meeting rooms, chat rooms, bots, integrations, and any Business Calling numbers.
2. Export or delete data - AWS asked customers to delete data they could not keep, and support can help.
3. Pick a destination - an off-the-shelf meeting product, or build with the Chime SDK if you need a custom experience.
4. Replace phone service - Business Calling stopped supporting SMS and calling after the cutoff. Voice Connector and SIP media applications in the SDK are a path for telephony.
5. Update links and automation - calendar invites, chatbots, and anything pointing at Chime meetings.

Per AWS's help notice, Team account users were converted to free Basic users on September 8, and Enterprise LWA domains and users were removed, so check each account type's status.

Start with the flow. Patients and clinicians sign in to your app. Your backend authorizes them, creates a meeting with attendees, and returns the join data. Media then flows directly between clients and Chime, while your backend handles side effects such as recording and audit.

flowchart LR
  P["Patient app"] --> API["API Gateway + Lambda"]
  D["Clinician app"] --> API
  API --> M["Chime SDK: CreateMeeting / CreateAttendee"]
  M --> V["Video visit"]
  V --> EB["EventBridge meeting events"]
  EB --> AU["Audit log + visit status"]
  V --> CP["Capture pipeline, if enabled"]
  CP --> S3["Encrypted S3 bucket"]
  V --> TR["Live captions via Transcribe Medical"]

Key design choices:

1. Authorization - verify the appointment before creating an attendee, and expire the meeting after the visit.
2. Roles - give the clinician SendReceive; restrict observers with Receive.
3. Region - pick a media region near the patient.
4. PHI handling - keep names and medical details out of ExternalUserId and ExternalMeetingId; use opaque IDs mapped in your database.
5. Recording and captions - record only with consent, store in KMS-encrypted S3, and use Transcribe Medical for captions if needed.
6. Compliance - the SDK is HIPAA eligible, but you need an AWS BAA and a compliant surrounding architecture.
7. Readiness - add the meeting readiness checker to a waiting room so connectivity issues surface before the visit starts.