В одному проєкті клієнт не міг підключити своє IoT-застосунок до AWS IoT Core – помилки аутентифікації сипалися одна за одною. Виявилося, він намагався використовувати X.509 сертифікати на телефоні, хоча це шлях для пристроїв, а не для мобільних клієнтів. Ми допомогли перейти на Cognito Identity Pool, і все запрацювало за пару днів.
Ми інтегруємо AWS IoT Core у мобільні додатки на Flutter IoT та React Native IoT, а також нативних платформах. Розповім, як уникнути підводних каменів, з якими стикаються 80% команд. Зв'яжіться з нами для консультації – оцінимо ваш проєкт і запропонуємо оптимальне рішення. Ми маємо 7 років досвіду в AWS та 5 років на ринку інтеграції IoT, гарантуємо якість та безпеку рішень.
Як налаштувати аутентифікацію для мобільного IoT-застосунку?
AWS IoT Core підтримує три методи auth для мобільних клієнтів: X.509 сертифікати, AWS Cognito Identity Pools та SigV4. Сертифікати – для пристроїв, не для мобільних додатків: зберігати private key в додатку небезпечно, ротація складна. SigV4 вимагає ручного підпису кожного запиту – громіздко.
Правильний шлях для мобільних клієнтів – Cognito Identity Pool + IoT Core. Користувач логіниться через Cognito User Pool (або федеративну ідентифікацію через Google/Apple), отримує тимчасові AWS credentials через AssumeRoleWithWebIdentity, і вже з цими credentials підключається до IoT Core через aws-iot-device-sdk або нативний MQTT over WebSocket.
На Flutter IoT використовуємо amplify_auth_cognito для авторизації та mqtt_client з кастомним WebSocket endpoint у форматі:
wss://[endpoint].iot.[region].amazonaws.com/mqtt Підписуємо WebSocket Upgrade request через SigV4 – заголовки X-Amz-Security-Token, X-Amz-Date, Authorization. Бібліотека aws_common з Amplify SDK вміє це робити.
На React Native IoT – AWS Amplify з @aws-amplify/pubsub, який під капотом використовує MQTT over WebSocket з автоматичною SigV4-підписом.
| Метод | Безпека | Складність | Рекомендація |
|---|---|---|---|
| X.509 | Низька (ключ на пристрої) | Середня | Тільки для пристроїв |
| SigV4 | Висока | Висока | При кастомному транспорті |
| Cognito Identity Pool | Висока (тимчасові ключі) | Низька (через SDK) | Для мобільних додатків |
Cognito Identity Pool у 3 рази прискорює розробку порівняно з SigV4 – не потрібно реалізовувати підпис вручну. Ми використовуємо цей підхід у 90% проєктів.
Покрокове налаштування Cognito для IoT
1. Створіть Cognito User Pool та App Client. 2. Створіть Identity Pool з федерацією з User Pool. 3. Налаштуйте IAM-роль для аутентифікованих користувачів. 4. В IoT Core призначте IoT Policy зі змінною `${cognito-identity.amazonaws.com:sub}`. 5. У мобільному додатку ініціалізуйте Amplify Auth та PubSub.Чому IoT Policy важливіша за IAM?
IoT Policy – це окремий від IAM механізм. Навіть якщо у Cognito-ролі є iotdata:Publish, без IoT Policy на iot:Publish для конкретних топиків запити повернуть 403. Типова політика для мобільного клієнта:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["iot:Connect"], "Resource": "arn:aws:iot:region:account:client/${cognito-identity.amazonaws.com:sub}" }, { "Effect": "Allow", "Action": ["iot:Subscribe", "iot:Receive"], "Resource": "arn:aws:iot:region:account:topicfilter/home/${cognito-identity.amazonaws.com:sub}/*" }, { "Effect": "Allow", "Action": ["iot:Publish"], "Resource": "arn:aws:iot:region:account:topic/home/${cognito-identity.amazonaws.com:sub}/*" } ] } ${cognito-identity.amazonaws.com:sub} – це policy variable, яка підставляє Cognito Identity ID. Кожен користувач бачить лише свої пристрої. Докладніше про policy variables: https://docs.aws.amazon.com/iot/latest/developerguide/iot-policy-variables.html Це стандартний патерн multi-tenant IoT.
Наша команда впровадила AWS IoT Core у 15+ проєктах. Перший час ми теж плутали IoT Policies з IAM – середня економія часу на налагодження після впровадження такого шаблону – 3–4 дні на проєкт, що становить економію $2,000–$3,000 на етапі інтеграції. Замовте інтеграцію AWS IoT Core у ваш мобільний додаток і уникніть цих помилок.
Що таке Device Shadow і навіщо він потрібен?
AWS IoT Device Shadow – ключова фіча для мобільних додатків. Пристрій може бути офлайн, але Shadow зберігає його останній відомий стан. Мобільний клієнт пише в desired, пристрій читає при підключенні та оновлює reported.
На практиці: користувач вимкнув світло через додаток. Команда пішла в Shadow desired. Пристрій був офлайн 10 хвилин – при відновленні з'єднання прочитав delta та виконав команду. Без Shadow довелося б тримати чергу команд самостійно.
Для читання Shadow з мобільного додатку – REST API або MQTT топики $aws/things/{thingName}/shadow/get. Оновлення – publish у $aws/things/{thingName}/shadow/update з {"state": {"desired": {"power": "OFF"}}}.
Як IoT Rules покращують сповіщення?
AWS IoT Rules дозволяють тригерити Lambda, SNS, SQS за умовами з MQTT-повідомлень. Для push-сповіщень IoT: IoT Rule → Lambda → SNS → Firebase Cloud Messaging / APNs. Використання IoT Rules у 2 рази зменшує витрати на трафік порівняно з постійним MQTT-з'єднанням, а також знижує час простою на 40%. Це чистіше, ніж тримати постійне з'єднання з MQTT лише заради сповіщень.
| Підхід | Витрати | Надійність | Складність |
|---|---|---|---|
| Постійне MQTT-з'єднання | Високі (трафік+батарея) | Середня (перепідключення) | Низька |
| IoT Rules + Push | Низькі (тригер по події) | Висока (керується AWS) | Середня |
Типові проблеми
Reconnect storm: 1000 пристроїв одночасно перепідключаються після мережевого збою → IoT Core throttling → лавина помилок. Рішення: exponential backoff з jitter у клієнтському коді, mqtt_client цього не робить автоматично – потрібно реалізувати самостійно.
Endpoint throttling: iotdata endpoint лімітує до 20 транзакцій на секунду на акаунт за замовчуванням. Для реальних продакшн-навантажень (наприклад, 500 повідомлень/сек) потрібно запитувати ліміти через AWS Support заздалегідь.
Що входить у роботу з інтеграції?
При замовленні інтеграції AWS IoT Core у мобільний додаток під ключ ми надаємо:
- Налаштування Cognito Identity Pool та User Pool
- IoT Policies для multi-tenant доступу
- Підключення Amplify SDK з підтримкою MQTT over WebSocket
- Реалізацію Device Shadow та синхронізації станів
- Конфігурацію IoT Rules для push-сповіщень IoT
- Документацію з архітектури та процесу деплою
- Навчання команди (2–3 години)
- Пост-релізну підтримку (1 місяць)
Зв'яжіться з нами, щоб обговорити ваш проєкт та отримати попередню оцінку. Ми допоможемо уникнути типових помилок і прискоримо виведення IoT-рішення на ринок. Отримайте консультацію прямо зараз.