Понимание причин создания одной или ограниченной глобальной корзины AWS S3 в организации.

Когда дело доходит до проектирования и создания корзины AWS S3 или Amazon Simple Storage Service в любой организации, особенно в крупных корпорациях, обычно мы начинаем с одной корзины S3 или, скорее, с ограниченного количества корзин S3 в зависимости от различных бизнес-единиц ( BU) или Verticals говорит о финансах, производстве и т. Д. В компании.

Всегда рекомендуется ограничивать ведро S3 по разным веским причинам и хранить данные централизованно.

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

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

В качестве хорошей практики компания может создать единую глобальную уникальную корзину S3 для различных сред, таких как песочница, разработка, контроль качества, предварительная подготовка и производство. И в этом сегменте различные инженерные группы могут получить доступ для создания / чтения / записи данных из своих собственных ограниченных префиксов (или подпапок в терминологии непрофессионала). Это даст организации больше контроля над своими данными, поскольку они хранятся централизованно и защищены. В качестве хорошей практики мы также можем включить отдельную корзину для централизованного ведения журнала, чтобы отслеживать все действия, выполняемые в этой области централизованных данных. Мы также можем включить различные свойства в этой централизованной корзине данных, такие как управление версиями и репликация данных, в качестве резервной копии для аварийного восстановления в других регионах AWS.

Классическим примером может служить ведро такого формата, как ‹bucket-name› - ‹environment› - ‹region› - ‹Идентификатор учетной записи AWS›.

global-bucket-sbx-ap-southeast-1–088853283839

Как показано на рисунке выше, значение имени экспорта - global-bucket, которое затем можно импортировать в любые другие шаблоны CloudFormation с помощью ! ImportValue global-bucket.

Примечание. И MyS3Bucket, и LoggingBucket, как показано на рисунке выше, являются только логическими именами. Фактическое имя корзины определяется на основе вашей среды и идентификатора учетной записи. Например, в этом случае как global-bucket-sbx-ap-southeast-1–088853283839 и global-loggings-sbx-ap-southeast-1–088853283839.

Хранение одного ведра дает следующие преимущества:

  1. Эксплуатационные расходы
  2. Легкость обслуживания
  3. Легкость ограничений

Давайте обсудим все по порядку.

  1. Эксплуатационные расходы. В качестве услуги S3 сам по себе является бесплатным и автоматически масштабируется, когда дело доходит до хранения больших объемов данных, однако при этом возникают эксплуатационные расходы, когда речь идет о вводе данных и вывод данных из сети и, конечно же, с другими ключевыми параметрами. Хранение данных, разбросанных по разным сегментам, приводит к не отслеживаемым операционным расходам (использование передачи по сети).
  2. Простота обслуживания. Не нужно беспокоиться об обслуживании различных сегментов, так как ваши команды DevOps должны управлять только одним сегментом. По мере роста компании ваша команда DevOps может предоставить доступ группе разработки или продукта к определенному префиксу в сегменте для чтения или записи данных в него, предоставив доступ на уровне сегмента. Вы можете написать один файл шаблона Infrastructure as Code (или IaC) (JSON или YAML) для централизованного создания Bucket с выходными данными в качестве значения экспорта, и в будущем любая ваша команда разработчиков может ссылаться на это значение экспорта в своем коде IaC (AWS CloudFormation или модель бессерверного приложения AWS). Также можно реализовать управление жизненным циклом в этом сегменте, чтобы сэкономить деньги.
  3. Легкость ограничений. Доступ будет предоставляться не на уровне сегмента (корневой или верхний), а только на уровне префикса или уровне подпапок. Ваши команды могут экспериментировать со своим префиксом

Типичный пример создания глобальной, централизованной и уникальной корзины AWS S3 на основе различных сред показан ниже путем написания этого шаблона AWS Cloud Formation: -

AWSTemplateFormatVersion: '2010-09-09'
Metadata: 
  License: Unlicensed
Description: >
  This template creates a global unique S3 bucket in a specific region which is unique. 
  The bucket name is formed by the environment, account id and region

Parameters:
 #https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html
  Environment:
    Description: This paramenter will accept the environment details from the user
    Type: String
    Default: sbx
    AllowedValues:
      - sbx
      - dev
      - qa
      - e2e
      - prod
    ConstraintDescription: Invalid environment. Please select one of the given environments only

Resources:
  #https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html
  MyS3Bucket:
      Type: AWS::S3::Bucket
      DeletionPolicy: Retain
      Properties: 
        BucketName: !Sub 'global-bucket-${Environment}-${AWS::Region}-${AWS::AccountId}' 
#https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html
        AccessControl: Private                
        LoggingConfiguration:
          DestinationBucketName: !Ref 'LoggingBucket'
          LogFilePrefix:  'access-logs'
        Tags:
          - Key: name
            Value: globalbucket
          - Key: department
            Value: engineering
  LoggingBucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain
    Properties:
      BucketName: !Sub 'global-loggings-${Environment}-${AWS::Region}-${AWS::AccountId}'
      AccessControl: LogDeliveryWrite      

Outputs:
  MyS3Bucket:
    Description: A private S3 bucket with deletion policy as retain and logging configuration
    Value: !Ref MyS3Bucket
    Export:
Name: global-bucket

Затем вы можете импортировать его в другие шаблоны, как показано ниже: -

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  hellolambda
  Sample SAM Template for hellolambda  
Globals:
  Function:
    Timeout: 3
Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello-world/
      Handler: app.lambdaHandler
      Runtime: nodejs12.x
      Events:
        HelloLambdaEvent:
        Type: S3
        Properties:
            Bucket: !ImportValue global-bucket
            Events: s3:ObjectCreated:*

Надеюсь, эта статья дала представление о важности сохранения единой архитектуры S3 в компании.

Делитесь своими отзывами и комментариями по этому поводу. :)

Ваше здоровье!

Больше контента на plainenglish.io