Інтеграція AWS IoT Core у мобільне IoT-додаток
AWS IoT Core — managed MQTT-брокер з аутентифікацією за X.509 сертифікатами, політиками доступу через AWS IAM/IoT Policies та можливістю масштабування до мільйонів пристроїв. Інтегрувати його у мобільний додаток не складно, але є кілька місць, де ошибаются майже все.
Аутентифікація: Що вибрати для мобільного клієнта
AWS IoT Core підтримує три методи auth для мобільних: X.509 сертифікати, AWS Cognito Identity Pools та SigV4. Сертифікати — для пристроїв, не для мобільних додатків: зберігання private key у додатку небезпечно, ротація складна.
Правильний шлях для мобільних клієнтів — Cognito Identity Pool + IoT Core. Користувач логінеться через Cognito User Pool (або федеративну ідентифікацію через Google/Apple), отримує тимчасові AWS credentials через AssumeRoleWithWebIdentity, і вже з цими credentials підключається до IoT Core через aws-iot-device-sdk або нативний MQTT over WebSocket.
На Flutter використовуємо 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 — AWS Amplify з @aws-amplify/pubsub, який під капотом використовує MQTT over WebSocket з автоматичною SigV4-підписю.
IoT Policies: Де режуться права
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. Кожен користувач бачить лише свої пристрої. Стандартний паттерн multi-tenant IoT.
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"}}}.
Rules Engine для повідомлень
AWS IoT Rules триггерять Lambda, SNS, SQS за умовами з MQTT. Для push: IoT Rule → Lambda → SNS → Firebase Cloud Messaging / APNs. Чистіше, ніж тримати постійне MQTT-з'єднання лише для повідомлень.
Типові проблеми
Reconnect storm: 1000 пристроїв одночасно переподключаються після мережевого сбою → IoT Core throttling → лавина помилок. Рішення: exponential backoff з jitter у клієнтському коді, mqtt_client це не робить автоматично — потребує самостійної реалізації.
Endpoint throttling: iotdata endpoint лімітує до 20 транзакцій в секунду на аккаунт за замовчуванням. Для реальних production-навантажень потребує запрашивання лімітів через AWS Support заздалегідь.
Процес та терміни
Налаштування Cognito + IoT Core + IoT Policies + базова інтеграція — 1–2 тижні. Device Shadow, Rules Engine, повідомлення — ще 1–2 тижні. Повна інтеграція з реальними пристроями та нагрузкове тестування — 4–6 тижнів. Стоимость рассчитывается после оценки количества устройств и частоты сообщений.