Облачные сервисы AWS и конечные точки для подключения приложений
Amazon Web Services (AWS) — организация, предоставляющая облачные сервисы для разработки и эксплуатации приложений и других рабочих нагрузок. Её предложения охватывают вычисления, хранение данных, базы данных, аналитику, интеграцию приложений и другие области. Важно понимать, что AWS предоставляет множество сервисов разного назначения, а не одно приложение с единым рабочим процессом.
Домен amazonaws.com представляет собой пространство имён конечных точек сервисов AWS, через которые программное обеспечение может подключаться к отдельным сервисам и ресурсам AWS. Общедоступный информационный сайт AWS находится по адресу aws.amazon.com, поэтому домен конечных точек и главная маркетинговая страница выполняют разные функции. Понимание этого различия помогает объяснить, почему приложение может обращаться к amazonaws.com, даже если пользователь не открывает сайт AWS.
Что AWS помогает создавать и эксплуатировать?
AWS начал работу в 2006 году и предоставляет облачные возможности, которые организации могут использовать для создания и эксплуатации рабочих нагрузок. В предоставленных официальных материалах описаны сервисы для запуска приложений, хранения информации, работы с базами данных и подключения распределённых систем. Поэтому выбор AWS предполагает определение необходимых рабочей нагрузке возможностей и изучение соответствующих сервисов.
Каталог сервисов показывает широту этого выбора, но не делает все сервисы взаимозаменяемыми. EC2 описывается как сервис виртуальных серверов, S3 — как объектное хранилище, а Lambda — как сервис для выполнения кода без управления серверами или кластерами. Это разные строительные блоки, хотя использующие их приложения могут отправлять запросы в пределах одной обширной группы доменов.
| Потребность рабочей нагрузки | Примеры из предоставленных материалов AWS | Практическое различие |
|---|---|---|
| Запуск рабочих нагрузок приложений | EC2 и Lambda | Вычислительные сервисы предлагают разные подходы к выполнению кода. |
| Хранение объектов | S3 | Объектное хранилище служит иной цели, чем реляционная база данных. |
| Работа с базами данных | RDS и DynamoDB | AWS включает сервисы реляционных баз данных и баз данных NoSQL. |
| Подключение компонентов приложения | API Gateway, SQS и Step Functions | Доступ через API, очереди сообщений и рабочие процессы решают разные задачи интеграции. |
| Анализ и наблюдение за рабочими нагрузками | Athena и CloudWatch | Запросы к данным и мониторинг работы — отдельные виды деятельности. |
Благодаря такому разнообразию AWS подходит разработчикам, которым нужны несколько облачных возможностей в рамках одной рабочей нагрузки. Вместе с тем возникает задача выбора: организация должна определить сервис, модель доступа и эксплуатационные обязанности, подходящие её приложению. Знакомый родительский домен не избавляет от необходимости принимать эти решения.
Для чего используется amazonaws.com?
В документации AWS конечная точка определяется как URL, служащий точкой входа в веб-сервис AWS. Многие конечные точки содержат amazonaws.com в имени хоста наряду с информацией, указывающей на сервис, а иногда и на регион AWS. Программное обеспечение использует эти адреса для обращения к соответствующей точке входа в сервис.
Запрос к конечной точке AWS может быть частью работы приложения, а не намеренным посещением сайта. Разные запросы в пределах родительского домена могут относиться к разным сервисам, учётным записям, ресурсам и моделям доступа. Их общий суффикс даёт меньше сведений о контексте приложения, чем полный запрос.
Как читать адрес конечной точки сервиса
Приведённый в документации пример dynamodb.us-west-2.amazonaws.com содержит больше полезной информации, чем один лишь amazonaws.com. Он указывает на DynamoDB и включает код региона us-west-2. Эти сведения сужают контекст до определённого сервиса, но не раскрывают всего об отправителе запроса или задействованном ресурсе.
- Название сервиса: помогает определить, к какой возможности AWS обращается приложение.
- Код региона: указывает региональный контекст, если конечная точка следует региональной схеме именования.
- Полное имя хоста: сохраняет различия, которые теряются, если при анализе оставить только родительский домен.
- Путь запроса: предоставляет дополнительный контекст запроса, который следует интерпретировать с помощью документации сервиса.
- Приложение, отправляющее запрос: помогает связать технический адрес с действиями, которых ожидает человек или организация.
Эти сведения следует рассматривать вместе. Имя хоста сервиса даёт полезную информацию об адресате, а приложение и запрос объясняют контекст использования этого адресата. Ни название сервиса, ни родительский домен сами по себе не определяют назначение задействованных данных.
Почему некоторые адреса AWS содержат регион?
Многие конечные точки AWS содержат код региона, поскольку предоставляют региональную точку входа в сервис. Для некоторых сервисов AWS также описывает общие и глобальные конечные точки. Точное поведение конечной точки зависит от конкретного сервиса, поэтому одну схему именования не следует распространять на весь каталог.
Для разработчика практический вопрос заключается в том, какая конечная точка указана в документации выбранного сервиса для нужной операции. Распознавание кода региона может помочь в изучении этого вопроса, но угадывание адреса по схеме другого сервиса не заменяет проверку. Отправными точками служат общий справочник AWS и документация по конечным точкам сервисов.
| Тип конечной точки | Что установлено в предоставленных исследовательских материалах | Что ещё нужно проверить |
|---|---|---|
| Региональная | Многие имена хостов включают код сервиса, код региона и amazonaws.com. | Конечную точку, указанную в документации для выбранного сервиса и региона. |
| Общая | У некоторых сервисов есть общие конечные точки. | Как конкретный сервис обрабатывает запросы, отправленные на эту конечную точку. |
| Глобальная | AWS описывает глобальные конечные точки для некоторых сервисов. | Какие операции и особенности регионального поведения описаны в документации сервиса. |
Преимущество отдельных конечных точек сервисов — более понятная маршрутизация и разделение возможностей. Для человека, изучающего сетевую активность, обратная сторона состоит в том, что запись с подстановочным знаком, например *.amazonaws.com, скрывает большую часть этих полезных сведений. Она объединяет адресаты, которые могут иметь существенно разное назначение.
Позволяет ли адрес AWS определить, кто управляет приложением?
Наличие amazonaws.com не позволяет определить клиента, рабочую нагрузку или владельца приложения, ответственного за конкретный запрос. AWS указывает на контекст облачного сервиса, но родительский домен не объясняет, какая учётная запись или какой ресурс стоит за этой активностью. Он также не устанавливает, какая информация хранится, извлекается или обрабатывается.
Это важно, когда кто-то замечает незнакомое соединение в активности приложения или сетевых записях. Адрес может помочь определить сервис AWS, но для интерпретации соединения нужны сведения о программном обеспечении, которое его устанавливает. Правильный вопрос — что это приложение делает при обращении к данному адресату.
При анализе полезно отдельно рассмотреть следующие вопросы:
- Какое приложение инициировало запрос? Свяжите адресат с изучаемым программным обеспечением и его активностью.
- Каков полный адрес назначения? Сохраните имя хоста и путь, а не только суффикс домена.
- Какому сервису он соответствует? Сопоставьте адрес с соответствующей документацией AWS.
- Какая операция ожидается? Установите, как запрос связан с предполагаемым поведением приложения.
- Какая модель доступа применяется? Проверьте учётные данные и разрешения, необходимые для этого сервиса и ресурса.
- Что остаётся необъяснённым? Оставьте вопросы о владельце, назначении данных или авторизации открытыми, если имеющийся контекст не позволяет на них ответить.
Такой подход позволяет не путать идентификацию инфраструктуры с идентификацией приложения. Он также делает расследование более предметным: неопределённость относительно запроса одного приложения превращается в вопрос об этом приложении и сервисе, а не в вывод обо всех адресатах с одинаковым суффиксом.
Как учётные данные и разрешения влияют на доступ?
Учётные данные и разрешения AWS отвечают на разные вопросы. Учётные данные подтверждают подлинность отправителя запроса, а разрешения определяют, какие действия он вправе выполнять. Знание того, какому сервису принадлежит конечная точка, не устанавливает, может ли конкретный отправитель запроса использовать конкретный ресурс.
Точные требования зависят от отдельного сервиса и его модели доступа. Разработчикам следует изучать обзор учётных данных безопасности AWS вместе с документацией по нужному сервису и операции. Само по себе существование конечной точки не описывает всех этих требований.
| Вопрос о доступе | Соответствующее понятие | Чего оно само по себе не устанавливает |
|---|---|---|
| Кто отправляет запрос? | Аутентификация с использованием учётных данных | Вправе ли отправитель выполнить запрошенное действие. |
| Вправе ли отправитель выполнить это действие? | Авторизация на основе разрешений | Разрешено ли также другое, не связанное с ним действие или использование другого ресурса. |
| Какие требования действуют здесь? | Документация конкретного сервиса | Универсальное правило доступа для всех конечных точек AWS. |
Ответственность не ограничивается распознаванием поставщика
AWS публикует модель совместной ответственности, которая помогает понять распределение обязанностей при использовании её сервисов. Это отдельный вопрос, не сводящийся к распознаванию имени хоста AWS. Командам нужно учитывать свои обязанности наряду с требованиями сервиса к доступу, а не предполагать, что установление поставщика решает вопросы на уровне приложения.
Предоставленные материалы позволяют объяснить это распределение в рамках оценки AWS. Они не устанавливают, как какой-либо конкретный клиент настроил приложение или ресурс. Для оценки конкретного развёртывания нужны сведения об этом развёртывании.
Следует ли организации разрешать или блокировать всю группу доменов?
Решение для всего домена имеет широкий охват, поскольку amazonaws.com включает множество сервисов и потенциально не связанных друг с другом рабочих нагрузок. Блокировка всей группы может нарушить работу приложений, зависящих от этих адресатов. Безусловное разрешение оставляет без объяснения происхождение и назначение отдельных запросов.
Ни один из вариантов не следует автоматически из наличия имени хоста AWS. Сетевому администратору нужны политика организации, сведения о назначении приложения, отправляющего запрос, и контекст адресата с учётом конкретного сервиса. Предоставленные исследовательские материалы обосновывают изучение этих подробностей перед определением подходящих границ доступа.
| Ситуация | Полезный следующий шаг | Ограничение имеющихся сведений |
|---|---|---|
| Известное приложение обращается к конечной точке AWS | Сопоставьте адресат с ожидаемым использованием сервисов приложением. | Знакомство с приложением не объясняет каждый запрос. |
| Незнакомый процесс обращается к amazonaws.com | Определите процесс и сохраните полный контекст запроса. | Родительский домен не указывает владельца процесса или его намерения. |
| Предлагаемое правило охватывает все поддомены | Оцените, какие приложения и сервисы затронет правило. | Подстановочный знак скрывает различия между отдельными адресатами. |
| Запрос выглядит подозрительным | Изучите приложение, ресурс и контекст соответствующего сервиса. | Принадлежность инфраструктуры AWS не гарантирует безопасность. |
Та же логика применима к человеку, который пытается разобраться в неожиданном адресе. Распознавание AWS может объяснить категорию инфраструктуры, но не позволяет окончательно определить, уместно ли соединение. Поведение приложения и назначение запроса остаются главными факторами.
Где разработчики могут найти документацию, помощь сообщества или контакты для сообщений о злоупотреблениях?
Каталог документации AWS служит общей отправной точкой для поиска руководств по сервисам. Общий справочник и страницы конечных точек сервисов особенно полезны при определении адресов и особенностей регионального поведения. Обзор учётных данных дополняет их объяснением аутентификации отправителя запроса.
AWS также предоставляет re:Post — сервис вопросов и ответов сообщества. Он даёт разработчикам возможность задавать вопросы об использовании AWS, а официальные контактные ресурсы позволяют обращаться за поддержкой и сообщать о предполагаемых злоупотреблениях. Обсуждения в сообществе и сообщения о злоупотреблениях служат разным целям, и выбирать между ними следует соответственно.
- Определить конечную точку: начните с общего справочника AWS и документации по конечным точкам.
- Разобраться в сервисе: найдите соответствующее руководство в каталоге документации.
- Уточнить требования к доступу: прочитайте обзор учётных данных вместе с документацией сервиса по разрешениям.
- Задать вопросы о реализации: обратитесь к сообществу AWS re:Post.
- Найти контакты или ресурсы для сообщений о злоупотреблениях: посетите официальную страницу контактов AWS.
- Изучить информацию AWS о конфиденциальности: ознакомьтесь с уведомлением о конфиденциальности AWS, отдельно изучив приложение, ответственное за запрос.
AWS предназначен для организаций и разработчиков, которым нужны облачные возможности для запуска приложений, хранения информации, интеграции компонентов и эксплуатации рабочих нагрузок. Имеющиеся сведения позволяют описать amazonaws.com как пространство имён конечных точек, соединяющих программное обеспечение с этими возможностями. Оно подходит читателям, оценивающим конкретные сервисы, и разработчикам, внедряющим их, при условии сохранения контекста сервиса, региона, приложения и доступа, который сам по себе родительский домен предоставить не может.
Успешный ответ не гарантирует безопасность. Измерения отражают одно наблюдение в определённый момент времени.