Інтеграція AWS S3 для зберігання файлів мобільного застосунку
Маємо 7+ років досвіду з AWS, реалізовано понад 50 проєктів. Уявіть: ваш застосунок генерує тисячі фотографій користувачів. Зберігати їх у базі даних — прямий шлях до деградації продуктивності. Передавати через власний бекенд — витрачати ресурси на зайвий hop і платити за трафік двічі. AWS S3 з пресайн-URL вирішує це завдання елегантно: клієнт заливає напряму в S3, а бекенд лише видає тимчасовий токен. За багаторічну роботу з AWS ми гарантуємо надійність та безпеку.
Навіщо інтеграція AWS S3 у мобільний застосунок?
Сучасні мобільні застосунки активно працюють з медіафайлами: аватари, зображення, документи, відео. Зберігання на пристрої обмежене та ненадійне. Власний сервер для файлів — це дорого та складно масштабувати. AWS S3 пропонує відмовостійке об'єктне сховище з глобальною доступністю та низькою вартістю. Додатково можна використовувати lifecycle rules для автоматичного видалення тимчасових файлів — це економить до 70% на зберіганні неактуальних даних.
Як працює завантаження через presigned URL?
Стандартна схема: мобільний клієнт запитує у бекенда попередньо підписане посилання, робить PUT-запит прямо в S3, потім повідомляє бекенд про завершення. Бекенд ніколи не бачить байти файлу — лише метадані. Це знижує навантаження та спрощує безпеку.
Покрокова інтеграція:
- Налаштуйте IAM role з правами s3:PutObject на конкретний prefix.
- Створіть S3 bucket з увімкненим CORS, якщо клієнт — web.
- На бекенді генеруйте presigned URL (термін дії — 5–15 хв).
- З мобільного клієнта виконайте PUT-запит до отриманого URL.
- Після успішного завантаження підтвердьте це на бекенді.
Приклад коду на iOS
// iOS: завантаження через presigned URL без SDK — через URLSession let presignedURL = URL(string: urlFromBackend)! var request = URLRequest(url: presignedURL) request.httpMethod = "PUT" request.setValue("image/jpeg", forHTTPHeaderField: "Content-Type") let uploadTask = URLSession.shared.uploadTask(with: request, fromFile: localFileURL) { data, response, error in guard let httpResponse = response as? HTTPURLResponse, httpResponse.statusCode == 200 else { // retry logic тут return } // Повідомляємо бекенд про успішне завантаження self.confirmUpload(fileKey: fileKey) } uploadTask.resume() На Android через OkHttp — аналогічно. Головне — не забути про Content-Type у заголовку: S3 перевіряє його збіг з тим, що було вказано при генерації presigned URL. Розбіжність дає 403.
Типові проблеми та їх вирішення
Таблиця нижче описує часті помилки та як їх уникнути.
| Проблема | Рішення |
|---|---|
| Закінчення терміну дії presigned URL до завантаження | Генерувати URL безпосередньо перед PUT-запитом, а не при відкритті picker |
| CORS помилки при веб-доступі | Налаштувати CORS policy на bucket — браузери блокують запит без неї |
| Завантаження великих файлів (від 5 МБ) | Використовувати Multipart Upload через API CreateMultipartUpload → UploadPart → CompleteMultipartUpload |
| Недостатні права доступу | Налаштувати IAM role з мінімальними правами на конкретні prefix (s3:PutObject) |
| Помилки мережі при завантаженні | Реалізувати exponential backoff з повторними спробами (retry) |
Для мультипарт завантаження на Android зручно використовувати Amplify Storage, який автоматично розбиває файл на частини.
// Android: використання Amplify для автоматичного multipart Amplify.Storage.uploadFile( StoragePath.fromString("uploads/${userId}/${filename}"), localFile, StorageUploadFileOptions.builder() .contentType("video/mp4") .build(), progress -> Log.i("Upload", "Progress: ${progress.fractionCompleted}"), result -> confirmUpload(result.path), error -> handleUploadError(error) ) Як налаштувати lifecycle rules для економії витрат?
Lifecycle rules дозволяють автоматично переміщувати файли в Glacier або Deep Archive після певного періоду, а потім видаляти. Наприклад, можна встановити правило: видаляти файли старші 30 днів. Це знижує витрати на зберігання до 70% для невикористовуваних даних.
Порівняння: прямий доступ до S3 і CloudFront CDN
Для медіафайлів, які використовуються багатьма користувачами, варто поставити CloudFront перед S3. Він кешує контент на edge-нодах, знижуючи затримки та навантаження на origin. Затримка з CloudFront у 5-10 разів нижча, ніж прямий S3 з іншого регіону.
| Параметр | Прямий S3 | S3 + CloudFront |
|---|---|---|
| Затримка | Висока для віддалених регіонів (200-400 мс) | Низька (10-50 мс з найближчого edge) |
| Безпека | S3 presigned URL | CloudFront signed URL |
| Вартість | Дешевше трафік всередині одного регіону | Дорожче, але кешування економить трафік |
| Георозподіл | Тільки регіон бакета | Глобально через 400+ точок |
Для presigned URL з CloudFront використовуйте CloudFront Signed URL, який вимагає власного підпису ключем.
Що входить в роботу під ключ
Ми пропонуємо повний цикл інтеграції:
- Аналіз вимог і проєктування схеми зберігання файлів
- Налаштування IAM ролей та bucket policies з мінімальними привілеями
- Реалізація завантаження/завантаження через presigned URL на iOS/Android
- Інтеграція з бекендом (ендпоінти для видачі URL)
- Налаштування CloudFront для медіафайлів
- Налаштування lifecycle rules для оптимізації витрат
- Тестування продуктивності та безпеки
- Документація та навчання команди розробки
Терміни та вартість
Базова інтеграція (одна платформа, presigned URL, без CDN): 3–5 днів, від $500. Повна реалізація з мультипарт, progress tracking, retry, lifecycle rules, CloudFront: 2–3 тижні, від $2000. Вартість розраховується індивідуально — зв'яжіться з нами для безкоштовної оцінки проєкту. Ми допоможемо підібрати оптимальне рішення.
Пишіть нам в Telegram або надішліть заявку — оцінимо проєкт безкоштовно. Замовте інтеграцію та отримайте надійне файлове сховище з мінімальними витратами на обслуговування. AWS S3