Архитектура AWS

У нас есть около 10 различных учетных записей AWS, я работаю над созданием приложения для просмотра активности на этих учетных записях. Деятельность состоит из разного запуска узлов, включая использование и затраты, связанные с каждой учетной записью. планирую показать его на внутреннем портале. Задача здесь - мне нужно хранить и показывать любые данные, которые я получаю от aws-sdk. Мне нужны некоторые предложения по архитектуре такой платформы, я бы хотел, чтобы данные были как можно скорее.Архитектура AWS

Любые предложения было бы здорово

источник

2015-05-06 user501307

Я думаю, ваш лучший выбор для архитектуры не является: нет. И причина в том, что вам это не нужно. Используйте CloudTrail для представления отчетов о действиях и выставления счетов за расходы. AWS теперь поддерживает федеративную учетную запись, и с помощью IAM вы можете легко настроить роль, которая может просто видеть эти данные для всех учетных записей.

источник

2015-05-06 18:42:07 MatteoSp

Не уверен, что если вы правильно поняли мой вопрос, у нас есть куча узлов под каждый account.By, имеющие нескольких учетных записей, трудно отслеживать узел. Я уже написал приложение, которое ежедневно собирает данные, хранит все данные инфраструктуры aws в базе данных mysql. Те же данные, что вы видите под 10 aws аккаунтами, я показываю в одном приложении. Единственное различие заключается в том, что я сортирую данные на основе команды, продуктов. Теперь я бы хотел сделать это больше в реальном времени, чем ежедневно. – user501307

Что вы подразумеваете под «отслеживать узел»? – MatteoSp

Имея данные в реальном времени, хранящиеся в любой момент времени, я могу отслеживать, сколько узлов было прекращено, остановлено или запущено в данный день.Когда я говорю, что узел трека я имел в виду использование инфраструктуры, такое как ELB, EC2, RDS и т. Д. Опять же, я не ищу метрики. Просто список используемых инфраструктур. Я могу получить эти данные с помощью aws-sdk, но, d, как хранить их, а также показывать их в приложении в реальном времени. Например, если пользователь запускает узел EC2 или RDS, я хотел бы получить информацию об этой инфраструктуре и показать ее на своем домашнем приложении. Задержка не должна быть больше 30-60 минут. – user501307

Посмотрите на traildash. Это все в одной приборной панели для cloudtrail. Другие комментарии на 100% правильны, AWS предоставляет большую часть этого уже, Traildash просто обертывает красивый графический интерфейс на нем.

источник

2015-05-21 05:19:27 Aitch

Не уверен, что этот вопрос был адресован, но fwiw вот мой прием.

Если я понял, этот вопрос касается того, как регулярно и автоматически отслеживать ресурсы aws (ec2, s3 и т. Д.) На нескольких учетных записях.

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

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

Для справки, вот пример политики доступа к EC2 экземпляров: учетная политика

обслуживание:

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
    { 
    "Sid": "", 
    "Effect": "Allow", 
    "Principal": { 
    "AWS": [ 
      "arn:aws:iam::ACCOUNT-ID-A:role/ROLE-A", 
      "arn:aws:iam::ACCOUNT-ID-B:role/ROLE-B”, 
      "arn:aws:iam::ACCOUNT-ID-C:role/ROLE-C”, 
      "arn:aws:iam::ACCOUNT-ID-D:role/ROLE-D”, 
      "arn:aws:iam::ACCOUNT-ID-E:role/ROLE-E”, 
    ] 
    }, 
    "Action": "sts:AssumeRole" 
    } 
    ] 
}

нормальная политика счета:

{ 
    "Version": "2012-10-17", 
    "Statement": { 
    "Effect": "Allow", 
    "Action": “ec2:DescribeInstances", 
    "Resource": “arn:aws:ec2:Account-ID-A:instance/*" 
}

источник

2015-06-26 21:33:25 Hua2308

AWS облако след является лучший вариант для вашего требования. Храните все журналы следов облаков на S3 и вытащите их туда, где вы хотите их показать. Вы можете использовать Graylog, например, инструменты агрегирования журналов, чтобы иметь возможность работать с решеткой и различные информационные панели на основе ваших требований.

Надеется, что это помогает ...

Благодаря Киранов

источник

2015-12-25 08:09:15 Kiran

ответ

Смежные вопросы