TIL

Beanstalk is a little bit... magic. Dunno yet if its good or not :

Elastic Beanstalk creates log volumes on the container instance, one for each container, at /var/log/containers/containername. These volumes are named awseb-logs-containername and should be mounted to the location within the container file structure where logs are written.

For example, the following mount point maps the nginx log location in the container to the Elastic Beanstalk–generated volume for the nginx-proxy container.

{
"sourceVolume": "awseb-logs-nginx-proxy",
"containerPath": "/var/log/nginx"
}

And all this logs can be copied into s3 automagically: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html#command-options-general-elasticbeanstalkhostmanager

Une policy IAM est constituée de statement, ce sont des règles (des blocs de codes)

{
"Statement":[{
"Effect":"effect",
"Action":"action",
"Resource":"arn",
"Condition":{
"condition":{
"key":"value"
}
}
}
]
}

Chaque règle dans sa forme la plus simple est composée de 3 choses :

Effect : allow ou deny

Action : quelle action concerne la règle

Resource : la resource concernée

Chaque service Amazon (EC2, ECR, etc...) expose une liste d'action, on peut trouver cette liste dans la doc (http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Action)

Et chaque resource peut être identifiée par un arn (une manière simple de retrouver un ARN est d'afficher la resources dans l'interface web AWS, il y a souvent l'arn)

online resources to prepare aws certifications

aws community guide

Donc AWS propose un service équivalent à elastic beats

L'agent est paramétrable pour collecter tel ou tel fichier de logs et les envoyer dans cloudwatch

EB

IAM

EC2
ELB
ECS

ELB
ECS
S3
RDS(Aurora)

VPC
Subnets
Routing
NAT
ACLs
Security groups
Group policy

Cloudwatch
Flowlogs

Q: What is a DB Subnet Group and why do I need one?

A DB Subnet Group is a collection of subnets that you may want to designate for your RDS DB Instances in a VPC. Each DB Subnet Group should have at least one subnet for every Availability Zone in a given Region. When creating a DB Instance in VPC, you will need to select a DB Subnet Group. Amazon RDS then uses that DB Subnet Group and your preferred Availability Zone to select a subnet and an IP address within that subnet. Amazon RDS creates and associates an Elastic Network Interface to your DB Instance with that IP address.

Please note that, we strongly recommend you use the DNS Name to connect to your DB Instance as the underlying IP address can change (e.g., during a failover).

For Multi-AZ deployments, defining a subnet for all Availability Zones in a Region will allow Amazon RDS to create a new standby in another Availability Zone should the need arise. You need to do this even for Single-AZ deployments, just in case you want to convert them to Multi-AZ deployments at some point.

Intéressant comme workflow, l'objectif est de laisser les users/soft créer des EC2 comme ils veulent et avoir les droits seulement sur les EC2 qu'ils ont créé.

Comment ça marche ? auto tagging des EC2 avec l'userid à la création couplé avec une policy qui autorise les action seulement si le tag avec l'userid est présent.

pacon

Dans le meme genre sans l'auto tagging :
http://blogs.aws.amazon.com/security/post/Tx29HCT3ABL7LP3/Resource-level-Permissions-for-EC2-Controlling-Management-Access-on-Specific-Ins