Справочник

Централизовать выставление счетов и применение политик, предоставляя бизнес-подразделениям административную автономию.

→Используйте узел организации с папками (Folders) для каждого бизнес-подразделения. Создавайте проекты внутри папок. Свяжите все проекты с одним платежным аккаунтом (Billing Account).

Почему: Папки (Folders) обеспечивают административные границы и наследование политик. Единый платежный аккаунт (Billing Account) централизует управление затратами и позволяет получать скидки для всей организации.

Источник↗

Уведомлять финансовый отдел, когда расходы по проекту достигают определенных процентов от бюджета.

→В Cloud Billing создайте бюджет (Budget) для проекта. Установите несколько правил порогов оповещения (например, 50%, 90%, 100%), которые отправляют уведомления в тему Pub/Sub или по электронной почте.

Почему: Бюджеты (Budgets) предназначены для оповещения, а не для остановки расходов. Чтобы автоматически ограничить расходы, уведомление Pub/Sub должно запускать Cloud Function для отключения биллинга или остановки ресурсов.

Источник↗

Анализировать детальные затраты на облачные ресурсы на уровне ресурсов и отслеживать расходы по центрам затрат.

→Включите детальный экспорт биллинга в набор данных BigQuery. Применяйте метки (например, `cost-center: "finance"`) к ресурсам. Запрашивайте таблицу BigQuery и группируйте по меткам для анализа.

Почему: Экспорт биллинга в BigQuery предоставляет наиболее детальные данные о затратах, включая метки, что крайне важно для пользовательских моделей начисления и учета затрат.

Источник↗

Обеспечить применение стандартов безопасности и конфигурации ко всем проектам в организации (например, ограничить местоположения ресурсов, требовать унифицированный доступ к бакетам, отключать публичные IP-адреса).

→Применяйте ограничения Организационных политик (Organization Policy constraints) на уровне Организации или Папки. Примеры: `gcp.resourceLocations` для обеспечения резидентности данных, `storage.uniformBucketLevelAccess` для безопасности GCS, `compute.vmExternalIpAccess` для предотвращения использования публичных IP-адресов.

Почему: Организационные политики наследуются и обеспечивают превентивный контроль, блокируя несовместимые действия до их возникновения. Это более эффективно, чем реактивный аудит.

Источник↗

Предотвратить случайное удаление критически важного производственного проекта.

→Наложите запрет на проект (lien) с помощью команды `gcloud alpha resource-manager liens create`.

Почему: Запрет (lien) — это свойство, которое блокирует удаление проекта. Он должен быть явно удален пользователем с ролью `resourcemanager.lienModifier` до того, как проект может быть удален.

Эффективно переключаться между различными проектами и учетными записями пользователей при использовании gcloud CLI.

→Используйте `gcloud config configurations create` для создания именованных конфигураций для каждого проекта/учетной записи. Переключайтесь между ними с помощью `gcloud config configurations activate [CONFIG_NAME]`

Почему: Конфигурации хранят такие настройки, как проект, учетная запись, регион и зона, что позволяет избежать необходимости указывать их при каждой команде.

Запустить бессерверный, контейнеризированный HTTP-микросервис без сохранения состояния с переменным трафиком, минимизируя операционные издержки и затраты.

→Разверните контейнер в Cloud Run.

Почему: Cloud Run является полностью управляемым сервисом, масштабируется до нуля (устраняя затраты в периоды простоя) и автоматически масштабируется в зависимости от входящих запросов. Он идеален для бессерверных веб-сервисов.

Источник↗

Запустить отказоустойчивую, гибкую по времени выполнения задачу пакетной обработки с минимально возможными затратами.

→Используйте Spot VMs (ранее Preemptible VMs) в управляемой группе экземпляров (Managed Instance Group).

Почему: Spot VMs предлагают скидку до 91% по сравнению с ценами по требованию. Они подходят для рабочих нагрузок, которые могут быть остановлены и перезапущены, как многие задачи пакетной обработки.

Развернуть веб-приложение, требующее высокой доступности (например, 99.9%) и автомасштабирования.

→Используйте региональную управляемую группу экземпляров (Regional Managed Instance Group - MIG) с политикой автомасштабирования, развернутую за глобальным внешним балансировщиком нагрузки HTTP(S) (Global External HTTP(S) Load Balancer).

Почему: Региональная MIG автоматически распределяет экземпляры по нескольким зонам для обеспечения отказоустойчивости. Автомасштабирование регулирует производительность для удовлетворения спроса, а балансировщик нагрузки предоставляет единую точку входа.

Хранить данные, которые часто доступны в течение 30 дней, затем редко в течение года, а затем архивируются.

→Храните в бакете Cloud Storage класса Standard. Создайте правило жизненного цикла для перехода объектов в Nearline/Coldline через 30 дней и в Archive через 365 дней.

Почему: Правила жизненного цикла автоматизируют оптимизацию затрат, перемещая данные в более дешевые классы хранения на основе возраста или других условий, без ручного вмешательства.

Источник↗

Глобально распределенному приложению требуется реляционная база данных с горизонтальной масштабируемостью и строгой согласованностью.

→Используйте Cloud Spanner.

Почему: Cloud Spanner — единственный сервис, который предоставляет глобально распределенную, строго согласованную реляционную базу данных с поддержкой SQL. Cloud SQL является региональным.

Приложению требуется управляемая база данных PostgreSQL или MySQL с SLA доступности 99.95% и автоматическим переключением при сбое.

→Используйте Cloud SQL с включенной конфигурацией высокой доступности (High Availability - HA).

Почему: Конфигурация HA создает основной экземпляр и резервный экземпляр в другой зоне. Данные синхронно реплицируются, и переключение при сбое происходит автоматически.

Разработать VPC для 3-уровневого приложения (веб, приложение, база данных), где уровень базы данных не должен быть доступен из интернета.

→Создайте VPC в пользовательском режиме (custom-mode) с отдельной подсетью для каждого уровня. Провизионируйте экземпляры базы данных только с частными IP-адресами в их выделенной подсети.

Почему: Изоляция уровней в отдельных подсетях позволяет использовать гранулированные правила файрвола. Отсутствие внешних IP-адресов на экземплярах баз данных является наиболее прямым способом предотвращения доступа из интернета.

Развернуть приложение с сохранением состояния (например, базу данных) в GKE, которое требует стабильных сетевых идентификаторов и постоянного хранилища.

→Используйте StatefulSet с шаблоном PersistentVolumeClaim.

Почему: StatefulSets разработаны для рабочих нагрузок с сохранением состояния, обеспечивая стабильные имена хостов (например, `pod-0`, `pod-1`) и автоматически выделяя уникальный PersistentVolume для каждой реплики.

Сервис Cloud Run, чувствительный к задержкам, должен избегать холодных запусков во время пиков трафика.

→Разверните сервис с флагом `--min-instances`, установленным на 1 или выше.

Почему: Установка минимального количества экземпляров поддерживает указанное число контейнеров "теплыми" и готовыми к обслуживанию запросов, устраняя задержку, связанную с запуском нового контейнера.

Автоматически выполнять бессерверную функцию при каждой загрузке нового файла в бакет Cloud Storage.

→Разверните Cloud Function (2-го поколения) с триггером Eventarc для события `google.cloud.storage.object.v1.finalized` в указанном бакете.

Почему: Eventarc предоставляет унифицированную, событийно-ориентированную архитектуру. Триггер GCS — это стандартный, управляемый способ подключения событий хранения к бессерверным вычислениям без опроса.

Развернуть новую версию приложения App Engine для тестирования без немедленной перенаправления на нее производственного трафика.

→Разверните новую версию с помощью `gcloud app deploy --no-promote`.

Почему: Флаг `--no-promote` создает новую версию, но не перенаправляет на нее трафик. Вы можете протестировать ее, используя URL-адрес, специфичный для версии, и вручную перенести трафик, когда будете готовы.

Создать глобальный балансировщик нагрузки HTTP(S) для веб-приложения, работающего на экземплярах Compute Engine.

→Создайте следующие компоненты в указанном порядке: группу экземпляров (Instance Group) с VM, проверку работоспособности (Health Check), бэкенд-сервис (Backend Service), указывающий на IG и HC, карту URL-адресов (URL Map), целевой прокси HTTP(S) (Target HTTP(S) Proxy) и глобальное правило перенаправления (Global Forwarding Rule) с публичным IP-адресом.

Почему: Эта последовательность правильно строит балансировщик нагрузки от бэкенда (экземпляров) до фронтенда (правила перенаправления). Каждый компонент служит определенной цели в маршрутизации и проверке работоспособности.

Команде необходимо совместно управлять состоянием Terraform, обеспечивая безопасность и предотвращая одновременные изменения.

→Используйте бакет Cloud Storage в качестве бэкенда Terraform. Включите версионирование объектов для истории и восстановления. Блокировка состояния автоматически обрабатывается бэкендом GCS.

Почему: Удаленный бэкенд GCS является стандартом для командной работы на GCP. Он обеспечивает блокировку для предотвращения повреждения состояния и версионирование для возможностей отката.

Получать уведомление, когда загрузка ЦП на любой VM в группе превышает 80% в течение длительного периода (например, 5 минут).

→В Cloud Monitoring создайте политику оповещения (Alerting Policy). Установите условие `Metric: CPU utilization > 80%` для `Duration: 5 minutes`. Настройте канал уведомлений (например, электронная почта, PagerDuty).

Почему: Cloud Monitoring — это нативный сервис для создания оповещений на основе метрик. Условие продолжительности критически важно для предотвращения "мерцающих" оповещений от коротких, нормальных всплесков использования.

Хранить определенные аудиторские журналы в течение 7 лет для соблюдения требований, а остальные журналы — в течение 30 дней.

→Создайте приемник журналов (log sink) с фильтром для аудиторских журналов. Настройте приемник для экспорта в бакет Cloud Storage. Примените политику хранения на 7 лет к бакету.

Почему: Cloud Logging имеет ограниченный период хранения (максимум 400 дней для административной активности). Приемники (sinks) — это механизм для маршрутизации журналов в долгосрочное, более дешевое хранилище, такое как GCS, или для анализа в BigQuery.

Под GKE находится в состоянии `CrashLoopBackOff`. Вам нужно просмотреть логи из контейнера непосредственно перед его сбоем.

→Используйте команду `kubectl logs [POD_NAME] --previous`.

Почему: Когда контейнер завершает работу с ошибкой и перезапускается, `kubectl logs` показывает логи *нового* контейнера. Флаг `--previous` необходим для просмотра логов завершенного экземпляра для диагностики сбоя.

Управляемая группа экземпляров должна автоматически заменять экземпляры, которые перестают отвечать.

→Настройте проверку работоспособности (например, HTTP, TCP) и примените ее к политике самовосстановления управляемой группы экземпляров.

Почему: MIG периодически опрашивает экземпляры на основе проверки работоспособности. Если экземпляр не проходит последовательные проверки, MIG автоматически удаляет и воссоздает его из шаблона, обеспечивая доступность приложения.

В базе данных Cloud SQL произошло событие повреждения данных. Вам необходимо восстановить базу данных до состояния, в котором она находилась за 5 минут до события.

→Предварительно убедитесь, что на экземпляре включено восстановление на момент времени (Point-in-Time Recovery - PITR). Выполните операцию восстановления, указав точную временную метку для восстановления.

Почему: PITR опирается на включенное бинарное логирование. Он позволяет выполнять гранулированное восстановление до любой точки времени в пределах окна хранения, что критически важно для минимизации потери данных (низкий RPO).

Автоматизировать ежедневное резервное копирование постоянного диска Compute Engine и хранить его в течение 14 дней.

→Создайте политику ресурсов (Resource Policy) для снимков дисков. Настройте ежедневное расписание и политику хранения на 14 дней. Прикрепите эту политику к целевому постоянному диску.

Почему: Расписания снимков — это управляемый, "поставил и забыл" способ автоматизации резервного копирования GCE. Это более надежно и поддерживаемо, чем использование заданий cron или пользовательских скриптов.

Экземпляру Compute Engine необходимо считывать данные из бакета Cloud Storage и записывать в таблицу BigQuery. Предоставьте минимально необходимые разрешения.

→Создайте пользовательскую учетную запись службы. Предоставьте ей роли `roles/storage.objectViewer` и `roles/bigquery.dataEditor`. Прикрепите эту учетную запись службы к экземпляру.

Почему: Использование пользовательской учетной записи службы со специфическими, предопределенными ролями позволяет избежать чрезмерно широких прав учетной записи службы Compute Engine по умолчанию, соблюдая принцип наименьших привилегий.

Предоставить пользователю разрешения на управление экземплярами GCE, но не на их удаление.

→Создайте пользовательскую роль IAM. Начните с разрешений из роли `roles/compute.instanceAdmin.v1` и удалите разрешение `compute.instances.delete`.

Почему: Пользовательские роли предоставляют гибкость для предоставления точного набора разрешений, когда предопределенные роли слишком широки или слишком ограничены для определенной должностной функции.

Разработчику необходимо подключиться по SSH к экземпляру Compute Engine, у которого нет внешнего IP-адреса, в соответствии с политикой безопасности.

→Предоставьте разработчику роль `roles/iap.tunnelResourceAccessor`. Затем они смогут подключиться, используя `gcloud compute ssh [INSTANCE_NAME] --tunnel-through-iap`.

Почему: Identity-Aware Proxy (IAP) TCP forwarding предоставляет безопасный, основанный на идентификации метод доступа к внутренним экземплярам без использования бастионных хостов, VPN или публичных IP-адресов.

Источник↗

Разрешить входящий SSH-трафик (порт 22) к определенным VM только из диапазона IP-адресов корпоративного офиса.

→Создайте правило файрвола VPC с `direction: INGRESS`, `action: ALLOW`, `protocol/ports: tcp:22`, `source ranges: [CORPORATE_IP_CIDR]` и `target tags: [например, "allow-ssh"]`. Примените тег к целевым VM.

Почему: Сочетание диапазонов источников и целевых тегов обеспечивает точный и масштабируемый способ контроля трафика. Оно ограничивает как *кто* может подключаться, так и *к чему* они могут подключаться.

Предотвратить копирование или доступ к данным из конфиденциального проекта BigQuery из-за пределов доверенной сетевой границы, даже при наличии действительных учетных данных.

→Настройте VPC Service Controls. Создайте периметр службы (service perimeter), который включает конфиденциальный проект и ограничивает BigQuery API.

Почему: VPC Service Controls создают виртуальный "периметр данных", который контролирует доступ на уровне API, обеспечивая надежную защиту от утечки данных, которую не могут обеспечить правила файрвола.

Предоставить стороннему приложению временный, ограниченный по времени доступ на чтение к определенному частному объекту в бакете Cloud Storage.

→Сгенерируйте подписанный URL (signed URL) для объекта с коротким сроком действия (например, 15 минут), используя учетную запись службы с разрешениями на чтение.

Почему: Подписанные URL-адреса предоставляют временный доступ к каждому объекту без необходимости для сторонней организации иметь учетную запись Google или разрешения IAM. Это самый безопасный метод для данного случая использования.

Поду GKE требуется безопасный доступ к Google Cloud API (например, Pub/Sub) без хранения ключей учетных записей служб в виде секретов Kubernetes.

→Включите Workload Identity в кластере GKE. Создайте учетную запись службы Google (Google Service Account - GSA) и учетную запись службы Kubernetes (Kubernetes Service Account - KSA). Привяжите KSA к GSA с помощью политики IAM. Настройте под для использования KSA.

Почему: Workload Identity — это рекомендуемый, бесключевой способ аутентификации приложений GKE в службах Google Cloud. Он сопоставляет идентификаторы KSA с идентификаторами GSA, что более безопасно, чем управление и ротация файлов ключей.

Источник↗

Политика организации требует, чтобы все данные в бакете Cloud Storage были зашифрованы с использованием ключа шифрования, который контролируется организацией.

→Создайте криптографический ключ в Cloud KMS. При создании бакета Cloud Storage укажите этот ключ в качестве ключа шифрования, управляемого клиентом (Customer-Managed Encryption Key - CMEK).

Почему: CMEK дает вам контроль над ключом, используемым для шифрования, включая ротацию и отзыв, при этом используя управляемую инфраструктуру шифрования Google.

Разрешить сотрудникам использовать их существующие локальные учетные данные Active Directory для доступа к ресурсам Google Cloud.

→Настройте Cloud Identity для федерации с Active Directory с использованием SAML 2.0. Пользователи проходят аутентификацию в AD, который затем подтверждает их личность в Google Cloud для доступа.

Почему: Федерация позволяет использовать единый вход (Single Sign-On - SSO) и централизует управление идентификацией в существующем IdP (Active Directory), избегая необходимости управлять отдельным набором паролей в Google Cloud.

Предоставить внешнему подрядчику временный доступ к проекту, который должен автоматически истечь через 30 дней.

→Добавьте подрядчика как члена IAM с требуемой ролью. Добавьте условие к привязке роли с временной меткой истечения срока действия (`request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`).

Почему: Условия IAM (IAM Conditions) предоставляют контроль доступа на основе атрибутов. Условия, основанные на времени, идеально подходят для временного доступа, так как они автоматически отзывают разрешения без ручной очистки.