AWS Devops : Developer Tools

AWS DEVOPS : Cheat Sheet

Code Commit

  • Code commit is an SCM [course code management ] tool for GIT , like [github/bitbucket]
  • There are two types of access HTTPS and SSH
  • IAM credential and code commit credential is different for HTTPS
  • For ssh, upload the public key, get the ssh user id, create a config file at local ssh, and that’s done
  • Users can browse the option but can not perform the option if policies are not granted. Policies are applied through IAM policies.
  • .You can create up to 10 triggers for each CodeCommit repository, Triggers can be subscribed to SNS /Lambda
  • Notification can be subscribed to SNS / chat bots
  • Cloudwatch Event can be used for automation
  • Code guru can be integrated for java/python codebase
  • Users in AccountB must have programmatic access, including an access key and secret key, to configure their local computers for access to the shared CodeCommit repository.
  • Code repo can be shared with other accounts using assume role
  • Data in CodeCommit repositories is encrypted in transit and at rest. The first time you create a CodeCommit repository in a new AWS Region in your Amazon Web Services account, CodeCommit creates an AWS managed key (the aws/codecommit key) in that same AWS Region in AWS Key Management Service (AWS KMS). This key is used only by CodeCommit (the aws/codecommit key).
  • A CodeCommit repository or CodeCommit approval rule template exists in the AWS Region where it was created
  • HTTPS (GRC) is the protocol to use with git-remote-codecommit (GRC). This utility provides a simple method for pushing and pulling code from CodeCommit repositories by extending Git. It is the recommended method for supporting connections made with federated access, identity providers, and temporary credentials.
  • PowerUser is not allowed to delete the repository
  • We can directly assign the Lambda to the event rather than going through SNS
  • Security and Monitoring
    • Data protection: shared, 
    • ACL: policy,
    •  Resiliency: regional service, and can push to two repo at once in a different region
    •  Monitoring: cloudtrail
  • Integration
    • Amplify
    • Cloud9
    • Cloud formation
    • Cloudtrianl
    • Cloudwatch events
    • Code build
    • Codeguru
    • Code Pipeline
    • Lodestar
    • Beanstalk
    • KMS
    • Lambda
    • SNS

Cloud Shell

  • Cloud shell is available if access is granted, with 1 gb storage for each user, in each region for 120 days if not accessed. The persistent storage is located in your home directory ($HOME) and is private to you.
  • Concurrent shells: You can run up to 10 shells at the same time in each AWS Region at no charge.
  • (Bash, PowerShell, or Z shell)
  • cloudwatch event bridge can be integrated
  • Security
    • The AWS CloudShell environment and its users are protected by specific security features such as IAM permissions management, shell session restrictions, and Safe Paste for text input.

Code Guru

  • Yes. After enabling CodeGuru Reviewer on your GitHub repository, for every push, pull, or scheduled repository scan there is a code review.
  • Cloudwatch can be integrated
  • You can use VPC endpoints when you call Amazon CodeGuru Reviewer APIs. When you use VPC endpoints, your API calls are more secure because they are contained within your VPC and do not access the internet. 

Cloud Control API

  • A wrapper against the existing libraries to provide a uniform way to access the existing API where nomenclature is different.
  • It exposes five common verbs (CreateResource, GetResource, UpdateResource, DeleteResource, ListResource) to manage the lifecycle of services.


AWS FIS supports actions for target resources for the following AWS services:

  • Amazon Elastic Compute Cloud (Amazon EC2)
  • Amazon Elastic Container Service (Amazon ECS)
  • Amazon Elastic Kubernetes Service (Amazon EKS)
  • Amazon Relational Database Service (Amazon RDS)

AWS Code Artifact 

  • Service to share the software package

AWS Code Build

  • You can choose the machine[pre-defined 4 types], network setting, os, queue options, certificates
  • You can pass parameters from plaintext/ AWS parameter / AWS secret manager
  • Can attach filesystem
  • Can upload build spec or type command in texarea. Build spec file name can be change
  • Finally block under buildspec file run in any case.
  • Manage environement : ami/ubuntu/windows server
  • Apart from git, s3 can also be used as a source for code build
  • We need to define a buildspec file, 
    • Env
      • variables
    • Phase
      • Install
      • Prebuild
      • Build
      • Postbuild
    • Reports
      • Report files
    • Artifacts 
      • Upload location
    • caches
  • You can use managed images as well as custom docker images from ECR/other ECR account or docker hub
  • An AWS CodeBuild project can take more than one input source. It can also create more than one output artifact.
  • AWS config can track AWS code build resources and config
  • One can debug the build locally using aws codebuild agent
  • Build system can be used to run test suites.
  • You can directly log to CW logs / or S3
  • Cloudwatch metrics are there
  • Cloudwatch events for automation [Code build state change {submited/ failed etc} / Code Build Phase Chanage]

Important Steps in Code Build File

AWS Code Pipeline

  • Encryption key AWS KMS | CMK
  • Source | code commit , ECR, S3, Bitbucket, GitHub, code commit
  • S3 is backbone of code pipeline as artifacts are stored
  • Change detection | cloudwatch events or pipeline polling for change
  • Output: pipeline default or full clone, including git metadata
  • Build : single build or batch: multiple builds in parallel [provider, Jenkins, pipiline]
  • Deploy to : app config, CF, CFstack, Code Deploy, Beanstalk, opsworks, service catalog, skillset, ECS, ECS Bluegreen, S3
  • Test:  codebuild, devicefarm, jenkins, blazemeter, ghost, micro focus, runscope
  • Can invoke: lambda, step function, synk
  • Provider step: approval, build, deploy, invoke, source, test, 
  • We can add steps to this,
  • We can use existing variables or can pass the variable from one stage to another, as lambda can be used and we can pass the variable as a function parameter
  • Action in the same action group run in parallel. From code, you can setup run order . default 1, if run order are same, then they run in parallel
  • Lambda can be used, and lambda needs to call [jobsuccessresultapi /jobfailedresult api] with continuation token
  • There is an option to clone the pipeline at interface
  • We can make a cross-account pipeline
  • AWS KMS can be used to encrypt the content


  • Plugins : aws amazon ec2 : can create jenkins slave
  • Jenkins code build plugin : use aws code build for build
  • Jenkins ec2 : launch slave into ecs 
  • S3 publishing, code pipeline to integrate aws code pipeline

There are other plugins as well. Jenkins can be used to replace codebuild as well as codepipeline / codebuild / code deploy


Code Deploy

  • You can deploy a nearly unlimited variety of application content

Source and deploy are must steps, build is optional

  • Code
  • Serverless AWS Lambda functions
  • Web and configuration files
  • Executables
  • Packages
  • Scripts
  • Multimedia files
  • There are five env variable
    • App name
    • Deployment id
    • Deployment group name
    • Deployment group id
    • Lifecycle event
  • Deploy on ec2/onpremise, lambda, ECS
  • On the basis of deployment group name, we can use if else in appsec file.
  • Filename can not be modified in code deploy . it must be appspec.yml
  • Deployment config : canary, liner, all at once
  • Deployment groups: set of ec2 basis of tag
  • Deployment type :
    • In place
    • Bluegreen
  • Need code deploy agent to run
  • Appsepc file to perform steps using hooks
    • ApplicationStopm
    • DownloadBundle
    • BeforeInstall
    • Install
    • AfterInstall
    • ApplicationStart
    • ValidateService
    • BeforeBlockTraffic
    • BlokcTraffic
    • AfterBlockTraffic
    • BeforeAllowTraffic
    • AllowTraffic
    • AfterAllowTrafic
  • The Start, DownloadBundle, Install, and End events in the deployment cannot be scripted.
  • hooks:
  •    deployment-lifecycle-event-name:
  •      – location: script-location
  •        timeout: timeout-in-seconds
  •        runas: user-name
  • In case of ec2 it is files, in case of lambda it is a resource
  • Incident management
    • AWS Lambda functions
    • Kinesis streams
    • Amazon SQS SQS queues
    • Built-in targets (CloudWatch alarm actions)
    • Amazon SNS topics
  • Monitoring through CW, SNS events, cloudtrail
  • Register instance for on-premise and tag them to include for deployment group
  • Blue/green on an AWS Lambda or Amazon ECS compute platform: Traffic is shifted in increments according to a canary, linear, or all-at-once deployment configuration. For more information, see Deployment configuration.
  • Blue/green deployments through AWS CloudFormation: Traffic is shifted from your current resources to your updated resources as part of an AWS CloudFormation stack update. Currently, only ECS blue/green deployments are supported.
  • You can stop the deployment: stop or stop and rollback
  • In env config: you can select ec2 auto scaling group/ec2/onpremise
  • Deployment setting [default] : one at time, half at time, all at once
  • You can define custom setting to make sure that a minimum number/percent of host are healthy
  • There are triggers that can be subscribed by SNS topic for various events like stats/fails/success/stop/ready/rollback/ etc
  • Rollbacks can be configured if the deployment fails or CW threshold breaches
  • All at once : success if deployed on at least one
  • There is no cancel option in an ongoing deployment, however there is stop and stop and rollback option
  • AWS lambda and AWS ECS supports canary deployment however EC2 does not support that
  • for lambda, hooks are beforeallowtraffic, afterallowtrafic
  • IN_placed deployment with LB, dereigster the instance->deploy->register agin
  • You can associate an Auto Scaling group with a deployment group to make sure that newly launched instances always get the latest version of your application. If you launch new instance from autoscaling group, code dpeloy will automatically deploy the latest successful application version
  • Tags are not required when deploying to autoscaling groups
  • Deployment Stratagies
    • In place : deployment is quick but creates an outage, as resources go offline during deployment. Aa loadbbalancer is required so that traffic is not being served.
    • Rolling Update : One group at a time, and on the success of that, next group
    • Blue green : make 2 copies of env and use route53 to switch or swap url 
    • Red black [making two asg, setting desired number]
    • Immutable [elastic beanstalk]
MethodImpact of failed deploymentDeploy timeZero downtimeNo DNS changeRollback processCode deployed to
Deploy in placeDowntimeRe-deployExisting instances
RollingSingle batch out of service. Any successful batches prior to failure running new application version.Re-deployExisting instances
Rolling with additional batch (beanstalk)Minimal if first batch fails, otherwise similar to rolling.Re-deployNew and existing instances
ImmutableMinimalRe-deployNew instances
Traffic splittingMinimalRe-route traffic and terminate new instancesNew instances
Blue/greenMinimalswitch back to old environmentNew instances

More to this:

Deployment Lifecycle EventDescription
ApplicationStopThis is the first deployment lifecycle event that occurs even before the revision gets downloaded. The AppSpec file and scripts used for this deployment lifecycle event are from the last successfully deployed revision.  You can use the ApplicationStop deployment lifecycle event if you want to gracefully stop the application or remove currently installed packages in preparation of a deployment.
DownloadBundleDuring this deployment lifecycle event, the agent copies the revision files to a temporary location on the instance. This deployment lifecycle event is reserved for the agent and cannot be used to run user scripts.
BeforeInstallYou can use the BeforeInstall deployment lifecycle event for preinstall tasks such as decrypting files and creating a backup of the current version.
InstallDuring this deployment lifecycle event, the agent copies the revision files from the temporary location to the final destination folder. This deployment lifecycle event is reserved for the agent and cannot be used to run user scripts.
AfterInstallYou can use the AfterInstall deployment lifecycle event for tasks such as configuring your application or changing file permissions.
ApplicationStartYou typically use the ApplicationStart deployment lifecycle event to restart services that were stopped during ApplicationStop.
ValidateServiceValidateService is the last deployment lifecycle event and is an opportunity to verify that the deployment completed successfully.
AWS DEVOPS : Cheat Sheet

Leave a Reply

Your email address will not be published. Required fields are marked *