Skip to main content

Configuration Management (CM) on Amazon Web Services (AWS)

Configuration Management (CM) in an AWS environment generally involves three areas:
  1. AWS resources such as CloudFormation Templates, Security Groups etc
  2. Operation System (OS)
  3. Application and supporting software/tools (also called application stack)
 There are AWS managed services as well as third party software to perform Configuration Management on AWS.
AWS recommendations for CM of AWS resources:
Inventory and Configuration Tracking of AWS Resources
  • AWS Config with Config Rules or an AWS Config Partner to provide a detailed, visual, and searchable inventory of AWS resources, configuration history, and resource configuration compliance.
Change Orchestration for AWS Resources
  • AWS CloudFormation or a third-party AWS-resource orchestration tool to manage AWS resource provisioning, update, and termination.
OS and Application Stack Management
  • AWS OpsWorks , BeanStalk or a third-party server configuration management tool to manage OS and application stack configuration changes.
 There are third party tools that leverage and extend AWS config. Feedback from such tools can be used as inputs to SIEM tools. For example Evident.io pulling information leveraging AWS Config and then feeding the information into Splunk SIEM.
As for CM of application stack , some common tools are Chef, Puppet, Ansible and Salt.

Comments

Popular posts from this blog

AWS Elasticache vs AWS RDS Read Replicas

AWS Elasticache vs AWS RDS Read Replicas (some very high level comparisons.) AWS Elasticache If the same read query is performed over and over again. AWS RDS Read Replica if the read query changes dynamically or has dynamic elements such as NOW(). AWS Elasticache is speed is required, since data is stored in RAM. AWS Read Replicas is there is a low tolerance for stale data. AWS Read Replica if the data returned by a read query is huge since RAM is not unlimited.

Business Development in the Government Sector - The Smarter You Work the Luckier You get..

Hamsterburger When the customer is asking for a hamburger , don’t put a hamster to make the burger. Even though what the customer wants (hamburger ) and what you have (hamster) share the part “ham” they are two different things. Analyze and understand requirements / ingredients for a hamburger Find out if you and your team has the ingredients  In case of gaps look for partners who has the missing ingredients. Time , Time and more Time The process of creating a response to a government solicitation is very similar to the SDLC of a project.  The way we need time to create a quality deliverable , we need time to deliver a quality solicitation response. Identify opportunities VERY VERY early on and start working on it (you may already follow Shipley type processes but may just not know that you are following it. Remember, there were great managers around before universities introduced MBAs). Don’t telescope everything in the last 20 days. Aspirations Don’t chase wi

AWS Application Load Balancer VS Network Load Balancer

AWS Application Load Balancer VS Network Load Balancer Distribution of Traffic: Application Load Balancer: Based on attributes of OSI Layer 7 (Application Layer). Network Load Balancer: Based on attributes of OSI Layer 4 (Transport Layer). Application Health Application Load Balancer: Since it works at the Application Layer of the OSI the health of the target application can be verified and the application health is taken into distribution decision. Network Load Balancer: Since it works at the Transport Later of the OSI level the health of the application can not be verified (it uses IP address , port etc). So it is possible that a request gets sent to a server even the the target application on that server is having some issues. Speed: Since Network Load Balancers work at a lower layer of the OSI they are faster then Application Load Balancers. More than one different application on the same server Since Network Load Balancers use IP address to distribute requ