Please enable JavaScript.

Coggle requires JavaScript to display documents.

Deployment, Provisioning, and Automation - Coggle Diagram

- - - - Usually Server-Side errors are 5XX
      - Usually Client-Side errors are 4XX
    - - Target host is unreachable
        
        Check if the traffic is allowed from the ELB to the targets on the target port
        
        Check SG and NACL and Route Table
    - - No registered targtes
    - - The Target of the ELB failed to respond
        
        The ELB could not establish connection to target
        
        Your app is having an issue
    - - Malformed Request, header missing or wrong or long
    - - The client did not send data before the idle timeout period expired
    - - The request is using an unsupported protocol
    - - Resource (e.g. file) is not publicly accessible
    - - Object doesn't exists
  - - - (default) Round Robin, distributes request to each target in turn. Good for request that are similar in complexity and your targets are all same size
        
        LOR Least Outstanding Request, sends requests to the target with least outstanding requests. Good for requests vary in complexity or if your target are not the same size. This has usually latency improvement, downside are:
        
        causing a flood of requests when a new target is added to the target group. For this reason ALB supports slow start to slowly ramp up the requests for a new target
        
        a failing target will often respond quicker than a healthy one, thus the failing target will receive a higher proportion of requests, causing a much larger incident
  - - - SurgeQueueLength measures the total number of requests queued by your CLB.
        
        The maximum SurgeQueueLength is 1024
        
        When requests exceed the maximum SurgeQueueLength, the SpilloverCount metric starts to measure rejected requests
- - - - Roll back all stack resources - roll back the stack to the last known stable state.
      - Preserve successfully provisioned resources - preserves the state of successfully provisioned resources, while rolling back failed resources to the last known stable state. Resources without a last known stable state will be deleted upon the next stack operation.
      - You can disable it for troubleshooting errors
    - - (Optional) Defines the resources that you want to protect from unintentional updates during a stack update
      - A stack policy is a JSON document that defines the update actions that can be performed on designated resources
    - - Monitoring time - (Optional) Number of minutes after the operation completes that CloudFormation should continue monitoring the specified alarms.
      - CloudWatch alarm - (Optional)
      - Specify alarms for CloudFormation to monitor when creating and updating the stack. If the operation breaches an alarm threshold, CloudFormation rolls it back.
    - - Timeout - The number of minutes before a stack creation times out
      - Termination protection - Prevents the stack from being accidentally deleted. Once created, you can update this through stack actions.
    - - CreationPolicy - prevent resource status from reaching create complete until AWS CloudFormation receives a specified number of success signals or the timeout period is exceeded. Use cfn-signal helper script or SignalResource API to signal creation. ResourceSignal parameters:
        
        Count
        
        Timeout
        
        DeletionPolicy - preserve, and in some cases, backup a resource when its stack is deleted. Also applies to stack update operations that lead to resources being deleted from stacks
        
        Delete - deletes the resource and all its content if applicable during stack deletion. It is the default, with exceptions: RDS Cluster and DB Instance default is Snapshot and S3 requires all objects to be deleted before deleting a bucket
        
        Retain - keeps the resource without deleting the resource or its contents when its stack is deleted
        
        Snapshot - for resources that support snapshots, CloudFormation creates a snapshot for the resource before deleting it
        
        DependsOn - specify that the creation of a specific resource follows another
        
        Metadata - add data in JSON or YAML to the resource declaration
        
        UpdatePolicy - specify how AWS CloudFormation handles updates to the few specific resource types (e.g. fleets, auto scaling group)
        
        UpdateReplacePolicy - retain or, in some cases, backup the existing physical instance of a resource when it's replaced during a stack update operation
    - - Enable you to write custom provisioning logic in templates that CloudFormation runs anytime you create, update (if you changed the custom resource), or delete stacks. For example: include resources that aren't available as AWS CloudFormation resource types, resources not yet supported by CF, on-premise resource, empty a bucket before being deleted, fetch AMI ID, ...
        CF Customer Resources --- Create / Update / Delete ---> AWS Lambda Function --- API Calls ---> Whatever with APIs
    - - The CloudFormation registry offers several advantages over custom resources, such advantages include:
        
        Supports the modeling, provisioning, and managing of third-party application resources
        
        Supports the Create, Read, Update, Delete, and List (CRUDL) operations
        
        Supports drift detection on private and third-party resource types
        
        Does not need to associate an Amazon SNS topic or a Lambda function to perform CRUDL operations
      - Lets you manage extensions, both public and private, such as resources, modules, and hooks that are available for use in your AWS account. Currently, you can use the following extension types in the AWS registry:
        
        resources types (includes a resource type specification and handlers that control API)
        
        modules (package resource configurations for inclusion across stack templates. Use modules to encapsulate common service configurations and best practices)
        
        hooks (proactively inspect the configuration of your AWS resources before provisioning)
    - - 1) create cross-stack references using Export field to flag the value of a resource Output for export
        
        2) use the Fn::ImportValue intrinsic function to import the value in any stack within the same Region/Account
        
        CloudFormation identifies exported values by the names specified in the template
        
        These names must be unique to your AWS Region and account
    - - a set of scripts that are included in the Amazon EC2 instances launched by AWS CloudFormation
        
        enable you to easily configure and customize EC2 instances and associated resources
      - cfn-init: Use to retrieve and interpret resource metadata, install packages, create files, and start services
        
        cfn-signal: Use to signal with a CreationPolicy or WaitCondition, so you can synchronize other resources in the stack when the prerequisite resource or application is ready
        
        cfn-get-metadata: Use to fetch a metadata block from CloudFormation and print it to standard out. Prints a sub-tree of the metadata block if you specify a key (only top-level keys are supported)
        
        cfn-hup: Use to check for updates to metadata and execute user-specified actions when a change is detected
    - - Import existing resources into existing/new stacks
        
        No need to delete and re-create
        
        You need a template that:
        
        describes the entire stack (original stack resources & target resources to import)
        
        references the Unique identifier for each resource to be imported (ex. BucketName for S3 buckets)
        
        Each resource to import must have a DeletionPolicy attribute (any value)
        
        Can’t import the same resource into multiple stacks
  - - - Basic permissions for stack set operations The simplest (and most permissive) permissions configuration is where you give all users and groups in the administrator account the ability to create and update all the stack sets managed through that account.
        The role in your administrator account should be named AWSCloudFormationStackSetAdministrationRole The role in each of your target accounts should be named AWSCloudFormationStackSetExecutionRole
      - Advanced permissions options for stack set operations If you need finer-grained control, you can set up permissions to specify:
        
        Which users and groups can perform stack set operations in which target accounts
        
        Which resources users and groups can include in their stack sets
        
        Which stack set operations specific users and groups can perform
        
        Create a trust relationship between each target account AWSCloudFormationStackSetExecutionRole and a specific customized administration role, rather than creating the AWSCloudFormationStackSetAdministrationRole service role in the administrator account itself. You then activate specific users and groups to use the customized administration role when performing stack set operations in a specific target account
- - - - Centralized access control to managed nodes using IAM policies
        
        No open inbound ports and no need to manage bastion hosts or SSH keys
        
        One-click access to managed nodes from the console and CLI
        
        Connect to both Amazon EC2 instances and non-EC2 managed nodes in hybrid and multicloud environments
        
        Port forwarding - Redirect any port inside your managed node to a local port on a client. After that, connect to the local port and access the server application that is running inside the node.
        
        Cross-platform support for Windows, Linux, and macOS
        
        Logging and auditing session activity CloudWatch Log and/or S3
        
        Secured using TLS
    - - You can send session log data to a CloudWatch Logs log group or S3 for debugging and troubleshooting purposes
        
        The default option is for log data to be sent with encryption using your KMS key, but you can send the data to your log group with or without encryption
        
        Stream session logs (Recommended)
        
        Upload session logs at the end of the session
        
        S3 logging - You can store and encrypt log data for all sessions in your account in an S3 bucket that you choose
        
        Linux/Windows shell profile - Specify environment variables, shell preferences, or commands you want to run when your session start