In API Gateway, an API’s method request can take a payload in a different format from the corresponding integration request payload, as required in the backend. Similarly, vice versa is also possible. API Gateway with a mapping template to translate the data from the backend format. The following mapping template does that.

#set($inputRoot = $input.path('$'))
{
  "choices": [
#foreach($elem in $inputRoot.bins)
    {
      "kind": "$elem.type",
      "suggestedPrice": "$elem.price per $elem.unit",
      "available": $elem.quantity
    }#if($foreach.hasNext),#end
            
#end
  ]
}

In API Gateway, a model defines the data structure of a payload. In API Gateway models are defined using the JSON schema draft 4.

Caching

A client of your API can invalidate an existing cache entry and reload it from the integration endpoint for individual requests. The client must send a request that contains the Cache-Control: max-age=0 header. The client receives the response directly from the integration endpoint instead of the cache, provided that the client is authorized to do so.

Autoscaling

Notifications

You can be notified when Amazon EC2 Auto Scaling is launching or terminating the EC2 instances in your Auto Scaling group. You manage notifications using Amazon Simple Notification Service (Amazon SNS) when the following events occur.

Lifecycle

The EC2 instances in an Auto Scaling group have a path, or lifecycle, that differs from that of other EC2 instances. The lifecycle starts when the Auto Scaling group launches an instance and puts it into service and ends when you terminate the instance.

Default quotas

Your AWS account has the following default quotas, formerly referred to as limits, for Amazon EC2 Auto Scaling.

Scaling

Scaling is the ability to increase or decrease the compute capacity of your application. Scaling starts with an event, or scaling action, which instructs an Auto Scaling group to either launch or terminate Amazon EC2 instances. Scaling options:

• Maintain current instance levels at all times
• Scale manually (specify only the change in the maximum, minimum, or desired capacity)
• Scale based on a schedule (function of date and time)
• Scale based on demand (use scaling policies that leverage CPU utilization)
• Use predictive scaling (proactive and reactive approaches)

Examples:

• ASGAverageCPUUtilization – This is a predefined metric for target tracking scaling policy. This represents the Average CPU utilization of the Auto Scaling group.
• ASGAverageNetworkOut – This is a predefined metric for target tracking scaling policy. This represents the Average number of bytes sent out on all network interfaces by the Auto Scaling group.
• ALBRequestCountPerTarget – This is a predefined metric for target tracking scaling policy. 

Note that these are out of the box configurations. You can also create custom configurations – for example, scale based on average RAM usage. You can create a custom CloudWatch metric for your EC2 Linux instance statistics by creating a script through the AWS Command Line Interface (AWS CLI). Then, you can monitor that metric by pushing it to CloudWatch.

Instance Distribution

Amazon EC2 Auto Scaling attempts to distribute instances evenly between the Availability Zones that are enabled for your Auto Scaling group. Amazon EC2 Auto Scaling does this by attempting to launch new instances in the Availability Zone with the fewest instances. Auto Scaling groups cannot span across multiple Regions.

Default Configurations

Detailed monitoring is enabled by default when you create a launch configuration using the AWS CLI or an SDK. By default, basic monitoring is enabled when you create a launch template or when you use the AWS Management Console to create a launch configuration.

Health Checks

By default, the health check configuration of your Auto Scaling group is set as an EC2 type that performs a status check of EC2 instances. To automate the replacement of unhealthy EC2 instances, you must change the health check type of your instance’s Auto Scaling group from EC2 to ELB by using a configuration file.

CloudFormation

You create a template that describes all the AWS resources that you want (like Amazon EC2 instances or Amazon RDS DB instances), and AWS CloudFormation takes care of provisioning and configuring those resources for you.

When you use AWS CloudFormation, you work with templates and stacks. You create templates to describe your AWS resources and their properties. Whenever you create a stack, AWS CloudFormation provisions the resources that are described in your template.

The cloudformation package command packages the local artifacts (local paths) that your AWS CloudFormation template references. The command will upload local artifacts, such as your source code for your AWS Lambda function.

The cloudformation deploy command deploys the specified AWS CloudFormation template by creating and then executing a changeset.

Templates

AWS CloudFormation uses these templates as blueprints for building your AWS resources. It is a JSON or YAML formatted text file.

AWSTemplateFormatVersion: "2010-09-09"
Description: A sample template
Resources:
  MyEC2Instance:
    Type: "AWS::EC2::Instance"
    Properties: 
      ImageId: "ami-0ff8a91507f77f867"
      InstanceType: t2.micro
      KeyName: testkey
      BlockDeviceMappings:
        -
          DeviceName: /dev/sdm
          Ebs:
            VolumeType: io1
            Iops: 200
            DeleteOnTermination: false
            VolumeSize: 20

The following shows template sections that can be used.

AWSTemplateFormatVersion: "version date"
Description: String
Metadata: template metadata
Parameters: set of parameters
Rules: set of rules
Mappings: set of mappings
Conditions: set of conditions
Transform: set of transforms
Resources: set of resources
Outputs: set of outputs

Parameters

Pseudo parameters are parameters that are predefined by AWS CloudFormation. You do not declare them in your template. Use them the same way as you would a parameter, as the argument for the Ref function. Examples:

• AWS::AccountId
• AWS::Region
• AWS::StackName

Parameters can be of the following types:

String – A literal string
Number – An integer or float
List<Number> – An array of integers or floats
CommaDelimitedList – An array of literal strings that are separated by commas
AWS::EC2::KeyPair::KeyName – An Amazon EC2 key pair name
AWS::EC2::SecurityGroup::Id – A security group ID
AWS::EC2::Subnet::Id – A subnet ID
AWS::EC2::VPC::Id – A VPC ID
List<AWS::EC2::VPC::Id> – An array of VPC IDs
List<AWS::EC2::SecurityGroup::Id> – An array of security group IDs
List<AWS::EC2::Subnet::Id> – An array of subnet IDs

Stacks

When you use AWS CloudFormation, you manage related resources as a single unit called a stack. You create, update, and delete a collection of resources by creating, updating, and deleting stacks. All the resources in a stack are defined by the stack’s AWS CloudFormation template.

Change sets

If you need to make changes to the running resources in a stack, you update the stack. Before making changes to your resources, you can generate a change set, which is a summary of your proposed changes. Change sets allow you to see how your changes might impact your running resources, especially for critical resources, before implementing them.

You don’t need to create a new stack and delete the old one. To update a stack, create a change set by submitting a modified version of the original stack template, different input parameter values, or both. AWS CloudFormation compares the modified template with the original template and generates a change set. The change set lists the proposed changes. After reviewing the changes, you can execute the change set to update your stack or you can create a new change set.

Cross-Reference Stacks

You can create a cross-stack reference to export resources from one AWS CloudFormation stack to another. For example, you might have a network stack with a VPC and subnets and a separate public web application stack. To use the security group and subnet from the network stack, you can create a cross-stack reference that allows the web application stack to reference resource outputs from the network stack. With a cross-stack reference, owners of the web application stacks don’t need to create or maintain networking rules or assets.

To create a cross-stack reference, use the Export output field to flag the value of a resource output for export. Then, use the Fn::ImportValue intrinsic function to import the value.

In the following examples, the output named StackVPC returns the ID of a VPC, and then exports the value for cross-stack referencing with the name VPCID appended to the stack’s name.

"Outputs" : {
  "StackVPC" : {
    "Description" : "The ID of the VPC",
    "Value" : { "Ref" : "MyVPC" },
    "Export" : {
      "Name" : {"Fn::Sub": "${AWS::StackName}-VPCID" }
    }
  }

Note – Exported Output Values in CloudFormation must have unique names within a single Region

Intrinsic Functions

AWS CloudFormation provides several built-in functions that help you manage your stacks. Intrinsic functions are used in templates to assign values to properties that are not available until runtime.

The intrinsic function Ref returns the value of the specified parameter or resource.!GetAtt – This function returns the value of an attribute from a resource in the template. !Join – This function appends a set of values into a single value, separated by the specified delimiter. The intrinsic function Fn::FindInMap returns the value corresponding to keys in a two-level map that is declared in the Mappings section. The intrinsic function Fn::Sub substitutes variables in an input string with values that you specify.

{ "Fn::FindInMap" : [ "MapName", "TopLevelKey", "SecondLevelKey"] }

CloudFront

Amazon CloudFront is a web service that speeds up distribution of your static and dynamic web content, such as .html, .css, .js, and image files, to your users. CloudFront delivers your content through a worldwide network of data centers called edge locations.

• If the content is already in the edge location with the lowest latency, CloudFront delivers it immediately.
• If the content is not in that edge location, CloudFront retrieves it from an origin that you’ve defined

After you configure CloudFront to deliver your content, here’s what happens when users request your files:

Video on Demand (VOD) or live streaming

CloudFront offers several options for streaming your media to global viewers—both pre-recorded files and live events.

Key Pairs

CloudTrail

With CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your AWS infrastructure. You can use AWS CloudTrail to answer questions such as – “Who made an API call to modify this resource?”. CloudTrail provides event history of your AWS account activity thereby enabling governance, compliance, operational auditing, and risk auditing of your AWS account. You cannot use CloudTrail to maintain a history of resource configuration changes.

• Think resource performance monitoring, events, and alerts; think CloudWatch.
• Think account-specific activity and audit; think CloudTrail.
• Think resource-specific history, audit, and compliance; think Config.

CodeBuild

AWS CodeBuild runs your builds in preconfigured build environments that contain the operating system, programming language runtime, and build tools (e.g., Apache Maven, Gradle, npm) required to complete the task. You just specify your source code’s location and select settings for your build, such as the build environment to use and the build commands to run during a build. AWS CodeBuild builds your code and stores the artifacts into an Amazon S3 bucket, or you can use a build command to upload them to an artifact repository. You can create, manage, and initiate build projects using AWS CodePipeline, the AWS Management Console, AWS CLIs, or SDKs.

You can bring your own build environments to use with AWS CodeBuild, such as for the Microsoft .NET Framework. You can package the runtime and tools for your build into a Docker image and upload it to a public Docker Hub repository or Amazon EC2 Container Registry (Amazon ECR). When you create a new build project, you can specify the location of your Docker image, and CodeBuild will pull the image and use it as the build project configuration.

buildspec.yml

A buildspec is a collection of build commands and related settings, in YAML format, that CodeBuild uses to run a build. You can include a buildspec as part of the source code or you can define a buildspec when you create a build project.

When possible, builds run concurrently. The maximum number of concurrently running builds can vary. Builds are queued if the number of concurrently running builds reaches its limit. The maximum number of builds in a queue is five times the concurrent build limit.

A build in a queue that does not start after the number of minutes specified in its time out value is removed from the queue. The default timeout value is eight hours.

You can override the build queue timeout with a value between five minutes and eight hours when you run your build. By setting the timeout configuration, the build process will automatically terminate post the expiry of the configured timeout.

Run CodeBuild with Agent – Local Build

With the Local Build you just specify the location of your source code, choose your build settings, and CodeBuild runs build scripts for compiling, testing, and packaging your code. You can use the AWS CodeBuild agent to test and debug builds on a local machine:

• Test the integrity and contents of a buildspec file locally.
• Test and build an application locally before committing.
• Identify and fix errors quickly from your local development environment.

Code Dependencies

CodeCommit

AWS CodeCommit is a version control service hosted by Amazon Web Services that you can use to privately store and manage assets (such as documents, source code, and binary files) in the cloud. Data in CodeCommit repositories is encrypted in transit and at rest. When data is pushed into a CodeCommit repository (for example, by calling git push), CodeCommit encrypts the received data as it is stored in the repository.

Access

IAM username and password credentials cannot be used to access CodeCommit. The valid credential types are:

• Git credentials
• SSH Keys
• AWS Access keys

CodeDeploy

AWS CodeDeploy is a service that automates code deployments to any instance, including Amazon EC2 instances and instances running on-premises. AWS CodeDeploy makes it easier for you to rapidly release new features, helps you avoid downtime during deployment, and handles the complexity of updating your applications. Amazon ECS blue/green deployments are supported through both CodeDeploy and AWS CloudFormation. The major components of CodeDeploy are:

Application: A name that uniquely identifies the application you want to deploy. CodeDeploy uses this name, which functions as a container, to ensure the correct combination of revision, deployment configuration, and deployment group are referenced during a deployment.

Compute platform: The platform on which CodeDeploy deploys an application.

Examples of how traffic routing:

• ECS / Lambda
  • Canary: Traffic is shifted in two increments. You can choose from predefined canary options that specify the percentage of traffic shifted to your updated Lambda function version in the first increment and the interval, in minutes, before the remaining traffic is shifted in the second increment.
  • Linear: Traffic is shifted in equal increments with an equal number of minutes between each increment. You can choose from predefined linear options that specify the percentage of traffic shifted in each increment and the number of minutes between each increment.
  • All-at-once: All traffic is shifted from the original Lambda function to the updated Lambda function version all at once.

Deployment group: A set of individual instances.  The deployment group contains settings and configurations used during the deployment. A deployment group contains individually tagged instances, Amazon EC2 instances in Amazon EC2 Auto Scaling groups, or both. Most deployment group settings depend on the compute platform used by your application. Some settings, such as rollbacks, triggers, and alarms can be configured for deployment groups for any compute platform.

In an EC2/On-Premises deployment, a deployment group is a set of individual instances targeted for deployment. A deployment group contains individually tagged instances, Amazon EC2 instances in Amazon EC2 Auto Scaling groups, or both.

Deployment type: The method used to make the latest application revision available on instances in a deployment group.

• In-place deployment: The application on each instance in the deployment group is stopped, the latest application revision is installed, and the new version of the application is started and validated. You can use a load balancer so that each instance is deregistered during its deployment and then restored to service after the deployment is complete. Only deployments that use the EC2/On-Premises compute platform can use in-place deployments. For more information about in-place deployments, see Overview of an in-place deployment.
• Blue/green deployment: The instances in a deployment group (the original environment) are replaced by a different set of instances (the replacement environment) using these steps. The behavior of your deployment depends on which compute platform you use.

IAM instance profile: An IAM role that you attach to your Amazon EC2 instances. T

Revision: An AWS Lambda deployment revision is a YAML- or JSON-formatted file that specifies information about the Lambda function to deploy.

Service role: An IAM role that grants permissions to an AWS service so it can access AWS resources.

Target revision: The most recent version of the application revision that you have uploaded to your repository and want to deploy to the instances in a deployment group. In other words, the application revision currently targeted for deployment

appspec.yml

The application specification file (AppSpec file) is a YAML-formatted or JSON-formatted file used by CodeDeploy to manage a deployment. For Amazon ECS compute platform applications, the AppSpec file is used by CodeDeploy to determine:

For AWS Lambda compute platform applications, the AppSpec file is used by CodeDeploy to determine:

If your application uses the EC2/On-Premises compute platform, the AppSpec file is named appspec.yml. It is used by CodeDeploy to determine:

An AppSpec file must be a YAML-formatted file named appspec.yml and it must be placed in the root of the directory structure of an application’s source code. Otherwise, deployments fail.

Lifecycle Event Hooks

• ValidateService: ValidateService is the last deployment lifecycle event. It is used to verify the deployment was completed successfully.
• AfterInstall – You can use this deployment lifecycle event for tasks such as configuring your application or changing file permissions.
• ApplicationStart – You typically use this deployment lifecycle event to restart services that were stopped during ApplicationStop.
• AllowTraffic – During this deployment lifecycle event, internet traffic is allowed to access instances after a deployment. This event is reserved for the AWS CodeDeploy agent and cannot be used to run scripts
• 

Cognito

Amazon Cognito user pools implements ID, access, and refresh tokens as defined by the OpenID Connect (OIDC) open standard:

The ID token is a JSON Web Token (JWT) that contains claims about the identity of the authenticated user such as name, email, and phone_number. You can use this identity information inside your application. The ID token can also be used to authenticate users against your resource servers or server applications.

User Pools

A user pool is a user directory in Amazon Cognito. With a user pool, your users can sign in to your web or mobile app through Amazon Cognito, or federate through a third-party identity provider (IdP).

Identity Pools

You can use Identity pools to grant your users access to other AWS services. With an identity pool, your users can obtain temporary AWS credentials to access AWS services, such as Amazon S3 and DynamoDB. Identity pools support anonymous guest users, as well as the specific identity providers that you can use to authenticate users for identity pools. Public providers: Login with Amazon (Identity Pools), Facebook (Identity Pools), Google (Identity Pools), Sign in with Apple (Identity Pools).

Cognito Sync

Amazon Cognito Sync is an AWS service and client library that enables cross-device syncing of application-related user data. You can use it to synchronize user profile data across mobile devices and the web without requiring your own backend.

Databases

AWS provides managed database through the RDS service. RDS can do automated backups, automated failure detection and recovery, and automated patching. Auto-scaling is also available but requires user configuration.

Access and Security

Communication between regions on AWS goes through the untrusted internet. You need to add the external IP of the EC2 instance to the security group of the RDS instance to get that to work. Configure the IP range of the US West region instance as the ingress security rule of RDS

By default, network access is turned off to a DB instance. You can specify rules in a security group that allows access from an IP address range, port, or security group. Once ingress rules are configured, the same rules apply to all DB instances that are associated with that security group. You can specify up to 20 rules in a security group. The status of the ingress rule is authorizing until the new ingress rule has been applied to all DB instances that are associated with the DB security group that you modified. After the ingress rule has been successfully applied, the status changes to authorized.

You can authenticate to your DB instance using AWS Identity and Access Management (IAM) database authentication. With this authentication method, you don’t need to use a password when you connect to a DB instance. Instead, you use an authentication token. An authentication token is a unique string of characters that Amazon RDS generates on request. Each token has a lifetime of 15 minutes. You don’t need to store user credentials in the database, because authentication is managed externally using IAM. This is supported in RDS MySQL and PostgreSQL only.

Encrypted Databases

Encryption for RDS is on by default and can also encrypt snapshots. However, some additional work is needed from client side when dealing with encrypted snapshots.

You can only enable encryption for an Amazon RDS DB instance when you create it, not after the DB instance is created. You can’t disable encryption on an encrypted DB instance. A snapshot of an encrypted DB instance must be encrypted using the same CMK as the DB instance.

With Amazon RDS, you can copy automated or manual DB snapshots. After you copy a snapshot, the copy is a manual snapshot. You can copy a snapshot within the same AWS Region, you can copy a snapshot across AWS Regions, and you can copy shared snapshots.

You can copy a snapshot that has been encrypted using an AWS KMS customer master key (CMK). If you copy an encrypted snapshot, the copy of the snapshot must also be encrypted. If you copy an encrypted snapshot within the same AWS Region, you can encrypt the copy with the same AWS KMS CMK as the original snapshot, or you can specify a different AWS KMS CMK. If you copy an encrypted snapshot across Regions, you can’t use the same AfWS KMS CMK for the copy as used for the source snapshot, because AWS KMS CMKs are Region-specific. Instead, you must specify a AWS KMS CMK valid in the destination AWS Region.

You can’t share a snapshot that’s encrypted using the default AWS KMS encryption key. For more information about the limitations of sharing DB snapshots, see Sharing an encrypted snapshot.

To share an encrypted Amazon RDS DB snapshot:

1. Add the target account to a custom (non-default) KMS key.
2. Copy the snapshot using the customer managed key, and then share the snapshot with the target account.
3. Copy the shared DB snapshot from the target account.

Backups

During backups the performance of RDS could be momentarily frozen, especially if in a single AZ.

DynamoDB has two built-in backup methods (On-demand, Point-in-time recovery) that write to Amazon S3, but you will not have access to the S3 buckets that are used for these backups.

Data Pipeline uses Amazon EMR to create the backup, and the scripting is done for you. This can be used to export DynamoDB table to S3 bucket and then download locally. Or use AWS Glue to copy your table to Amazon S3. This is the best practice to use if you want automated, continuous backups that you can also use in another service, such as Amazon Athena.

DynamoDB Atomicity

You can use the UpdateItem operation to implement an atomic counter—a numeric attribute that is incremented, unconditionally, without interfering with other write requests. (All write requests are applied in the order in which they were received.) With an atomic counter, the updates are not idempotent. In other words, the numeric value increments each time you call UpdateItem.

DynamoDB transactions provide developers atomicity, consistency, isolation, and durability (ACID) across one or more tables within a single AWS account and region. You can use transactions when building applications that require coordinated inserts, deletes, or updates to multiple items as part of a single logical business operation.

DynamoDB Conditional Writes

Conditional writes – DynamoDB optionally supports conditional writes for write operations (PutItem, UpdateItem, DeleteItem). A conditional write succeeds only if the item attributes meet one or more expected conditions. Otherwise, it returns an error.

DynamoDB Consistent Reads

DynamoDB uses eventually consistent reads by default. To change, do ConsistentRead = true for GetItem operation.

Eventually Consistent Reads

When you read data from a DynamoDB table, the response might not reflect the results of a recently completed write operation. The response might include some stale data. If you repeat your read request after a short time, the response should return the latest data.

Strongly Consistent Reads

When you request a strongly consistent read, DynamoDB returns a response with the most up-to-date data, reflecting the updates from all prior write operations that were successful.

DynamoDB Optimization / Reduce Latency

When you’re not making requests, consider having the client send dummy traffic to a DynamoDB table. Alternatively, you can reuse client connections or use connection pooling. All of these techniques keep internal caches warm, which helps keep latency low.

DynamoDB Global Tables

If you have globally dispersed users, consider using global tables. With global tables, you can specify the AWS Regions where you want the table to be available. This can significantly reduce latency for your users.

Amazon Redshift is a fully managed, petabyte-scale data warehouse service in the cloud. An Amazon Redshift data warehouse is a collection of computing resources called nodes, which are organized into a group called a cluster. Each cluster runs an Amazon Redshift engine and contains one or more databases.

Amazon Redshift achieves extremely fast query execution by employing these performance features.

• Massively parallel processing
• Columnar data storage
• Data compressin
• Query optimizer
• Result caching
• Compiled code

Data Pipeline

AWS Data Pipeline is a web service that you can use to automate the movement and transformation of data. With AWS Data Pipeline, you can define data-driven workflows, so that tasks can be dependent on the successful completion of previous tasks.

• A pipeline definition specifies the business logic of your data management.
• A pipeline schedules and runs tasks by creating Amazon EC2 instances to perform the defined work activities. You upload your pipeline definition to the pipeline, and then activate the pipeline. You can edit the pipeline definition for a running pipeline and activate the pipeline again for it to take effect.
• Task Runner polls for tasks and then performs those tasks.

For example, you can use AWS Data Pipeline to archive your web server’s logs to Amazon Simple Storage Service (Amazon S3) each day and then run a weekly Amazon EMR (Amazon EMR) cluster over those logs to generate traffic reports.

Data Pipeline can work with other storage services such as DynamoDB, RDS, Redshift and S3.

Direct Connect

AWS Direct Connect links your internal network to an AWS Direct Connect location over a standard Ethernet fiber-optic cable. One end of the cable is connected to your router, the other to an AWS Direct Connect router. With this connection, you can create virtual interfaces directly to public AWS services (for example, to Amazon S3) or to Amazon VPC, bypassing internet service providers in your network path.

You must create one of the following virtual interfaces to begin using your AWS Direct Connect connection.

EC2

Convertible Reserved instances – A Convertible Reserved Instance can be exchanged during the term for another Convertible Reserved Instance with new attributes including instance family, instance type, platform, scope, or tenancy.

Standard Reserved instances – With Standard Reserved Instances, some attributes, such as instance size, can be modified during the term; however, the instance family cannot be modified. You cannot exchange a Standard Reserved Instance, only modify it

Scheduled Reserved instances – Scheduled Reserved Instances (Scheduled Instances) enable you to purchase capacity reservations that recur on a daily, weekly, or monthly basis, with a specified start time and duration, for a one-year term. You reserve the capacity in advance so that you know it is available when you need it.

Spot Instances

You can specify that Amazon EC2 should do one of the following when it interrupts a Spot Instance:

• Stop the Spot Instance
• Hibernate the Spot Instance
• Terminate the Spot Instance
• The default is to terminate Spot Instances when they are interrupted.

Dedicated Instances / Hosts

Dedicated Instances are Amazon EC2 instances that run in a virtual private cloud (VPC) on hardware that’s dedicated to a single customer. Dedicated Instances that belong to different AWS accounts are physically isolated at a hardware level, even if those accounts are linked to a single-payer account.

Dedicated Hosts and Dedicated Instances can both be used to launch Amazon EC2 instances onto physical servers that are dedicated for your use. There are no performance, security, or physical differences between Dedicated Instances and instances on Dedicated Hosts.  An Amazon EC2 Dedicated Host is a physical server with EC2 instance capacity fully dedicated to your use. Dedicated Hosts allow you to use your existing software licenses on EC2 instances. With a Dedicated Host, you have visibility and control over how instances are placed on the server. This option is costlier than the Dedicated Instance.

User Data

User Data is generally used to perform common automated configuration tasks and even run scripts after the instance starts. When you launch an instance in Amazon EC2, you can pass two types of user data – shell scripts and cloud-init directives. By default, these run with root user privileges and runs only during the boot cycle when you first launch an instance. Must be configured if needed to run at every restart.

Metadata

To view all categories of instance metadata from within a running instance, use the following URI – http://169.254.169.254/latest/meta-data/. The IP address 169.254.169.254 is a link-local address and is valid only from the instance. All instance metadata is returned as text (HTTP content type text/plain).

The 169.254.0.0/16 range is a reserved IPv4 address space. Used for link-local addresses^[6] between two hosts on a single link when no IP address is otherwise specified, such as would have normally been retrieved from a DHCP server.

Key Pairs

In the Select an existing key pair or create a new key pair dialog box, you can choose an existing key pair, or create a new one. If you choose the Proceed without key pair option, you won’t be able to connect to the instance unless you choose an AMI that is configured to allow users another way to log in.

Systems Manager

Elastic Beanstalk

Elastic Beanstalk reduces management complexity without restricting choice or control. You simply upload your application, and Elastic Beanstalk automatically handles the details of capacity provisioning, load balancing, scaling, and application health monitoring. Elastic Beanstalk uses AWS CloudFormation to launch the resources in your environment and propagate configuration changes. Elastic Beanstalk uses Amazon Elastic Container Service (Amazon ECS) to coordinate container deployments to multi-container Docker environments.

It is best suited for those groups who want to deploy and manage their applications within minutes in the AWS cloud. As a bonus, you don’t even need experience with cloud computing to get started.

Health Colors

For basic health, these metrics are published every five minutes and can be monitored with graphs in the environment management console. With enhanced health, the Elastic Beanstalk health agent reports metrics to Elastic Beanstalk every 10 seconds.

• Green (OK) – All health checks passed
• Yellow (Warning) – Moderate number of request failures or taking long time
• Red (Degraded) – high number of failures
• Red (Severe) – high number of failures
• Green (Info) – operation in progress and completing
• Gray (Pending) – operation in progress within timeout, ie launching
• Gray (Unknown) – no data
• Gray (Suspended) – monitoring stopped

Deployment

The following table compares deployment method properties.

Deployment methods
Method	Impact of failed deployment	Deploy time	Zero downtime	No DNS change	Rollback process	Code deployed to
All at once	Downtime		No	Yes	Manual redeploy	Existing instances
Rolling	Single batch out of service; any successful batches before failure running new application version	†	Yes	Yes	Manual redeploy	Existing instances
Rolling with an additional batch	Minimal if first batch fails; otherwise, similar to Rolling	†	Yes	Yes	Manual redeploy	New and existing instances
Immutable	Minimal		Yes	Yes	Terminate new instances	New instances
Traffic splitting	Percentage of client traffic routed to new version temporarily impacted	††	Yes	Yes	Reroute traffic and terminate new instances	New instances
Blue/green	Minimal		Yes	No	Swap URL	New instances

† Varies depending on batch size.

Detach RDS instances from main environment

Note: An RDS DB instance attached to an Elastic Beanstalk environment is ideal for development and testing environments. However, it’s not ideal for production environments because the lifecycle of the database instance is tied to the lifecycle of your application environment. If you terminate the environment, then you lose your data because the RDS DB instance is deleted by the environment. There are no ways to do selective deletes in Beanstalk.

Configuration File

.ebextensions/<mysettings>.config : You can add AWS Elastic Beanstalk configuration files (.ebextensions) to your web application’s source code to configure your environment and customize the AWS resources that it contains. Any resources created as part of your .ebextensions is part of your Elastic Beanstalk template and will get deleted if the environment is terminated.

Elastic Block Store EBS

Amazon Elastic Block Store (Amazon EBS) provides block level storage volumes for use with EC2 instances. EBS volumes behave like raw, unformatted block devices.

Attaching / Detaching

Before detaching an EBS volume, make sure to unmount it from within the OS to ensure no file system damage occurs. Note that a volume can be attached to running instances as long as it is in the same AZ as the instance. When you create an EBS volume, it is automatically replicated within its Availability Zone to prevent data loss due to the failure of any single hardware component. You can attach an EBS volume to an EC2 instance in the same Availability Zone.

If your volume stays in the detaching state, you can force the detachment by choosing Force Detach. Use this option only as a last resort to detach a volume from a failed instance, or if you are detaching a volume with the intention of deleting it.

ElastiCache

Amazon ElastiCache makes it easy to set up, manage, and scale distributed in-memory cache environments in the AWS Cloud. It provides a high performance, resizable, and cost-effective in-memory cache, while removing complexity associated with deploying and managing a distributed cache environment. It works with both the Redis and Memcached engines.

Redis Engine

ElastiCache for Redis has multiple features that help make the service more reliable for critical production deployments:

Memcached Engine

Choose Memcached if the following apply for you:

• You need the simplest model possible.
• You need to run large nodes with multiple cores or threads.
• You need the ability to scale out and in, adding and removing nodes as demand on your system increases and decreases.
• You need to cache objects.
• Does not support encryption, therefore does not meet many compliance certifications

Elastic Container Service ECS

Amazon Elastic Container Service (Amazon ECS) is a highly scalable, fast container management service that makes it easy to run, stop, and manage containers on a cluster. Your containers are defined in a task definition that you use to run individual tasks or tasks within a service. In this context, a service is a configuration that enables you to run and maintain a specified number of tasks simultaneously in a cluster.

When the following conditions are required, we recommend that you deploy your containers in a single task definition:

Elastic Load Balancer ELB

Elastic Load Balancing automatically distributes your incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones. It monitors the health of its registered targets, and routes traffic only to the healthy targets.

Elastic Load Balancing supports the following load balancers: Application Load Balancers, Network Load Balancers, Gateway Load Balancers, and Classic Load Balancers.

A load balancer serves as the single point of contact for clients. The load balancer distributes incoming traffic across multiple targets, such as Amazon EC2 instances.

A listener checks for connection requests from clients, using the protocol and port that you configure, and forwards requests to a target group.

Each target group routes requests to one or more registered targets, such as EC2 instances, using the TCP protocol and the port number that you specify. You can register a target with multiple target groups.

Sends traffic to instances when they recover from UNHEALTHY state. Multiple ELBs can always share instances.

Note that Load Balancer is not capable of launching instances by itself if it’s not configured with an Auto Scaling Group.

Sessions

ELBs can use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user’s session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance. If your application has its own session cookie, then you can configure Elastic Load Balancing so that the session cookie follows the duration specified by the application’s session cookie. If your application does not have its own session cookie, then you can configure Elastic Load Balancing to create a session cookie by specifying your own stickiness duration. Elastic Load Balancing creates a cookie, named AWSELB, that is used to map the session to the instance.

SSL Termination / HTTPS Listener

ELB will not allow you to create SSL for backend. If a user is configuring HTTPS on the front end and TCP on the back end, ELB will not allow saving these listeners and will respond with the message. “Load Balancer protocol is an application layer protocol, but instance protocol is not. Both the Load Balancer protocol and the instance protocol should be at the same layer. Please fix.”

To use an HTTPS listener, you must deploy at least one SSL/TLS server certificate on your load balancer. You can create an HTTPS listener, which uses encrypted connections (also known as SSL offload). This feature enables traffic encryption between your load balancer and the clients that initiate SSL or TLS sessions. As the EC2 instances are under heavy CPU load, the load balancer will use the server certificate to terminate the front-end connection and then decrypt requests from clients before sending them to the EC2 instances.

Authentication

Application Load Balancer can be used to securely authenticate users for accessing your applications. This enables you to offload the work of authenticating users to your load balancer so that your applications can focus on their business logic. You can use Cognito User Pools to authenticate users through well-known social IdPs, such as Amazon, Facebook, or Google, through the user pools supported by Amazon Cognito or through corporate identities, using SAML, LDAP, or Microsoft AD, through the user pools supported by Amazon Cognito.

Cross Zone Load Balancing

If cross-zone load balancing is enabled, each of the 10 targets receives 10% of the traffic. This is because each load balancer node can route its 50% of the client traffic to all 10 targets.

If cross-zone load balancing is disabled:

This is because each load balancer node can route its 50% of the client traffic only to targets in its Availability Zone.

ALB access logs – Elastic Load Balancing provides access logs that capture detailed information about requests sent to your load balancer. Each log contains information such as the time the request was received, the client’s IP address, latencies, request paths, and server responses.

ALB request tracing – You can use request tracing to track HTTP requests. The load balancer adds a header with a trace identifier to each request it receives. Request tracing will not help you to analyze latency specific data.

Health Checks

The load balancer routes requests only to the healthy instances. When the load balancer determines that an instance is unhealthy, it stops routing requests to that instance. The load balancer resumes routing requests to the instance when it has been restored to a healthy state. NOTE – ELB does not terminate instances based on health checks – that can be done by Auto Scaler.

The ELB can perform a health check on HTTP, HTTPS, TCP and SSL protocols.

Error Codes

IAM

Trust policy – Trust policies define which principal entities (accounts, users, roles, and federated users) can assume the role. An IAM role is both an identity and a resource that supports resource-based policies. For this reason, you must attach both a trust policy and an identity-based policy to an IAM role. The IAM service supports only one type of resource-based policy called a role trust policy, which is attached to an IAM role.

AWS Organizations Service Control Policies (SCP) – If you enable all features of AWS organization, then you can apply service control policies (SCPs) to any or all of your accounts. SCPs are JSON policies that specify the maximum permissions for an organization or organizational unit (OU). The SCP limits permissions for entities in member accounts, including each AWS account root user. An explicit deny in any of these policies overrides the allow.

Access control list (ACL) – Access control lists (ACLs) are service policies that allow you to control which principals in another account can access a resource. ACLs cannot be used to control access for a principal within the same account. Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs.

Permissions boundary – AWS supports permissions boundaries for IAM entities (users or roles). A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity’s permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.

Cross Account Access and Alias URLs

You can allow IAM users of another account to access your account by setting up an IAM permission policy and attaching it to each IAM user. Then on the API method authorization type to AWS_IAM and use signature Version 4 to sign the API requests. Example:

{
   "Version": "2012-10-17",
   "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::account-id-2:user/Alice",
                    "account-id-2"
                ]
            },
            "Action": "execute-api:Invoke",
            "Resource": [
                "execute-api:/stage/GET/pets"
            ]
        }
    ]
}

https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html#apigateway-resource-policies-cross-account-example

You can give a Lambda function created in one account (“account A”) permissions to assume a role from another account (“account B”) to access resources such as DynamoDB or S3 bucket. You need to create an execution role in Account A that gives the Lambda function permission to do its work. Then you need to create a role in account B that the Lambda function in account A assumes to gain access to the cross-account DynamoDB table. Make sure that you modify the trust policy of the role in Account B to allow the execution role of Lambda to assume this role. Finally, update the Lambda function code to add the AssumeRole API call.

Login Alias URL

It is not possible to have the same IAM account login URL for separate AWS accounts. It is also not possible to have capitol letters in the alias name.

Signature Version 4 (SigV4)

Signature Version 4 is the process to add authentication information to AWS requests sent by HTTP. For security, most requests to AWS must be signed with an access key, which consists of an access key ID and secret access key. These two keys are commonly referred to as your security credentials.

How signing AWS requests with SigV4 works.

1. Create a canonical request.
2. Use the canonical request and additional metadata to create a string for signing.
3. Derive a signing key from your AWS secret access key. Then use the signing key, and the string from the previous step, to create a signature.
4. Add the resulting signature to the HTTP request in a header or as a query string parameter.

Policy Generator

The AWS Policy Generator is a tool that enables you to create policies that control access to Amazon Web Services (AWS) products and resources.

https://awspolicygen.s3.amazonaws.com/policygen.html

Policy Simulator

With the IAM policy simulator, you can test and troubleshoot identity-based policies, IAM permissions boundaries, Organizations service control policies (SCPs), and resource-based policies. Note this is not part of IAM console.

https://policysim.aws.amazon.com/

Policy Variables

Instead of creating individual policies for each user, you can use policy variables and create a single policy that applies to multiple users (a group policy). Policy variables act as placeholders. When you make a request to AWS, the placeholder is replaced by a value from the request when the policy is evaluated.

IAM policy principal – You can use the Principal element in a policy to specify the principal that is allowed or denied access to a resource (In IAM, a principal is a person or application that can make a request for an action or operation on an AWS resource. The principal is authenticated as the AWS account root user or an IAM entity to make requests to AWS).

X.509 Certificates

You can have AWS create an X.509 certificate and private key that you can download, or you can upload your own certificate by using the Security Credentials page. For IAM users, you must create the X.509 certificate (signing certificate) by using third-party software. After you create the certificate, you attach it to an IAM user by using IAM. As far as I know, this is legacy functionality, no longer serving any useful purpose. Many years ago, X.509 certificates were used to sign requests for AWS SOAP APIs.

Billing and Cost Management

By default, IAM users do not have access to the AWS Billing and Cost Management console. You or your account administrator must grant users access. You can do this by activating IAM user access to the Billing and Cost Management console and attaching an IAM policy to your users. Then, you need to activate IAM user access for IAM policies to take effect. You only need to activate IAM user access once.

IAM Access Analyzer

AWS IAM Access Analyzer helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity.

Access Advisor on IAM console

To help identify the unused roles, IAM reports the last-used timestamp that represents when a role was last used to make an AWS request. Your security team can use this information to identify, analyze, and then confidently remove unused roles.

MFA

SMS-based MFA is available only for IAM users, you cannot use this type of MFA with the AWS account root user. Hardware – generates six-digit numeric code. U2F security key, plugs into USB port and uses open authentication standard hosted by the FIDO Alliance. Virtual MFA is a software app that runs on phone or other device and emulates a physical hardware.

STS / decode-authorization-message

AWS Security Token Service (AWS STS) is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users). Credentials that are created by using account credentials can range from 900 seconds (15 minutes) up to a maximum of 3,600 seconds (1 hour), with a default of 1 hour. Hence you need to renew the credentials post expiry.

STS is not supported by API Gateway.

Use decode-authorization-message to decode additional information about the authorization status of a request from an encoded message returned in response to an AWS request. If a user is not authorized to perform an action that was requested, the request returns a Client.UnauthorizedOperation response (an HTTP 403 response). The message is encoded because the details of the authorization status can constitute privileged information that the user who requested the operation should not see. To decode an authorization status message, a user must be granted permissions via an IAM policy to request the DecodeAuthorizationMessage (sts:DecodeAuthorizationMessage) action.

Kinesis

Kinesis Data Stream

You can use Amazon Kinesis Data Streams to collect and process large streams of data records in real time. A typical Kinesis Data Streams application reads data from a data stream as data records. These applications can use the Kinesis Client Library, and they can run on Amazon EC2 instances. You can send the processed records to dashboards, use them to generate alerts, dynamically change pricing and advertising strategies, or send data to a variety of other AWS services.

The type of data used can include IT infrastructure log data, application logs, social media, market data feeds, and web clickstream data. Because the response time for the data intake and processing is in real time, the processing is typically lightweight.

Workers and Shards

Each KCL consumer application instance uses “workers” to process data in Kinesis shards. At any given time, each shard of data records is bound to a particular worker via a lease. For the given use-case, an EC2 instance acts as the worker for the KCL application. You can have at most one EC2 instance per shard in Kinesis for the given application. As we have 10 shards, the max number of EC2 instances is 10.

Capacity Limits / ProvisionedThroughputExceeded 

The capacity limits of an Amazon Kinesis data stream are defined by the number of shards within the data stream. The limits can be exceeded by either data throughput or the number of PUT records. While the capacity limits are exceeded, the put data call will be rejected with a ProvisionedThroughputExceeded exception. If this is due to a temporary rise of the data stream’s input data rate, retry (with exponential backoff) by the data producer will eventually lead to the completion of the requests. Another reason for this exception could be due to a partition key that is not distributed well. The partition key is used by Kinesis Data Streams to distribute data across shards. Kinesis Data Streams segregates the data records that belong to a stream into multiple shards, using the partition key associated with each data record to determine the shard to which a given data record belongs.

Enhanced Fan Out

You should use enhanced fan-out if you have, or expect to have, multiple consumers retrieving data from a stream in parallel. Therefore, using enhanced fan-out will not help address the ProvisionedThroughputExceeded exception as the constraint is the capacity limit of the Kinesis Data Stream.

Kinesis Data Stream vs SQS

Some benefits of SQS that Data Streams may not be able to do or not do as well:

Amazon SQS tracks the ack/fail, so the application does not have to maintain a persistent checkpoint/cursor. Amazon SQS will delete acked messages and redeliver failed messages after a configured visibility timeout. With Amazon SQS, you can configure individual messages to have a delay of up to 15 minute. SQS dynamically increases concurrency and throughput, Data Streams can scale up to a sufficient number of shards but you’ll need to provision enough shards ahead of time.

Some benefits of using Data Streams over SQS:

Routing related records to the same record processor (as in streaming MapReduce). Ordering of records. Ability for multiple applications to consume the same stream concurrently. For example, you have one application that updates a real-time dashboard and another that archives data to Amazon Redshift. You want both applications to consume data from the same stream concurrently and independently. Ability to consume records in the same order a few hours later, or up to 365 days later. As multiple applications are consuming the same stream concurrently, both SQS Standard and SQS FIFO are not the right fit for the given use-case.

Kinesis Data Firehouse

Amazon Kinesis Data Firehose is the easiest way to load streaming data into data stores and analytics tools. It can capture, transform, and load streaming data into Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, and Splunk, enabling near real-time analytics with existing business intelligence tools and dashboards you’re already using today.

Kinesis Data Firehose is used to load streaming data into data stores (Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, and Splunk) whereas Kinesis Data Streams provides support for real-time processing of streaming data. It provides ordering of records, as well as the ability to read and/or replay records in the same order to multiple downstream Amazon Kinesis Applications.

Kinesis Data Analytics

Amazon Kinesis Data Analytics is the easiest way to analyze streaming data in real-time. You can quickly build SQL queries and sophisticated Java applications using built-in templates and operators for common processing functions to organize, transform, aggregate, and analyze data at any scale.

KMS

AWS Key Management Service (AWS KMS) is a managed service that makes it easy for you to create and control customer master keys (CMKs), the encryption keys used to encrypt your data. AWS KMS CMKs are protected by hardware security modules (HSMs) that are validated by the FIPS 140-2 Cryptographic Module Validation Program.

KMS stores the CMK, and receives data from the clients, which it encrypts and sends back

Customer Master Keys (CMKs)

Customer master keys are the primary resources in AWS KMS. A customer master key (CMK) is a logical representation of a master key. The CMK includes metadata, such as the key ID, creation date, description, and key state. The CMK also contains the key material used to encrypt and decrypt data.

By default, AWS KMS creates the key material for a CMK. You cannot extract, export, view, or manage this key material. Also, you cannot delete this key material; you must delete the CMK. However, you can import your own key material into a CMK or create the key material for a CMK in the AWS CloudHSM cluster associated with an AWS KMS custom key store.

Customer managed CMKs are CMKs in your AWS account that you create, own, and manage. You have full control over these CMKs, including establishing and maintaining their key policies, IAM policies, and grants, enabling and disabling them, rotating their cryptographic material, adding tags, creating aliases that refer to the CMK, and scheduling the CMKs for deletion.

Asymmetric vs Symmetric Keys

AWS KMS supports symmetric and asymmetric CMKs. A symmetric CMK represents a 256-bit key that is used for encryption and decryption. An asymmetric CMK represents an RSA key pair that is used for encryption and decryption or signing and verification (but not both), or an elliptic curve (ECC) key pair that is used for signing and verification

Asymmetric = key pair (2 keys, public and private). This also allows the encryption/decryption operation to happen outside of the service the user is trying to access.

Symmetric = single key. The encryption/decryption must happen at the service endpoint. This is because AWS KMS will put in cipher-text produced by symmetric keys with a specific KMS metadata.

Max Size

Lambda

AWS Lambda is a compute service that lets you run code without provisioning or managing servers. The total size of all environment variables doesn’t exceed 4 KB. There is no limit defined on the number of variables that can be used.

Lambda Storage

Can use the “/tmp” directory storage for up to 512MB. This gets deleted once Lambda completes.

Lambda Layers

You can configure your Lambda function to pull in additional code and content in the form of layers. A layer is a .zip file archive that contains libraries, a custom runtime, or other dependencies. With layers, you can use libraries in your function without needing to include them in your deployment package.

Layers can be uploaded as a zip file or referenced from an S3 bucket. Layers must have runtime configured (ex Nodejs, python, etc). The layers can also be versioned, just like any other lambda function. When referencing the layer files, it must be done through the ‘opt/foldername’.

Concurrency

Concurrency is the number of requests that a Lambda function is serving at any given time. If a Lambda function is invoked again while a request is still being processed, another instance is allocated, which increases the function’s concurrency.

To ensure that a function can always reach a certain level of concurrency, you can configure the function with reserved concurrency. When a function has reserved concurrency, no other function can use that concurrency. More importantly, reserved concurrency also limits the maximum concurrency for the function, and applies to the function as a whole, including versions and aliases.

• Function concurrency
• Reserved concurrency
• Unreserved concurrency
• Throttling

To enable your function to scale without fluctuations in latency, use provisioned concurrency. By allocating provisioned concurrency before an increase in invocations, you can ensure that all requests are served by initialized instances with very low latency. You can configure Application Auto Scaling to manage provisioned concurrency on a schedule or based on utilization. Use scheduled scaling to increase provisioned concurrency in anticipation of peak traffic.

Alias

Alias can only point to function version, not to another alias. User routing configuration on an alias to send a portion of traffic to a second function version. This can reduce the risk of deploying a new version by configuring the alias to send most of the traffic to the existing version, and onl small percentage of traffic to the new version.

Stages (used with APIGW)

Stage variables are name-value pairs that you can define as configuration attributes associated with a deployment stage of an API. They act like environment variables and can be used in your API setup and mapping templates.

Serverless Application Model SAM

The AWS Serverless Application Model (SAM) is an open-source framework for building serverless applications. SAM supports the following resource types:

• AWS::Serverless::Api – creates APIGW
• AWS::Serverless::Application
• AWS::Serverless::Function
• AWS::Serverless::HttpApi
• AWS::Serverless::LayerVersion
• AWS::Serverless::SimpleTable – creates DynamoDB table with single attribute primary key
• AWS::Serverless::StateMachine

SAM Templates

Presence of ‘Transform’ section indicates it is a Serverless Application Model (SAM) template – The AWS::Serverless transform, which is a macro hosted by AWS CloudFormation, takes an entire template written in the AWS Serverless Application Model (AWS SAM) syntax and transforms and expands it into a compliant AWS CloudFormation template.

Transform and Resources are the only required sections in a SAM template.

OpsWork

AWS OpsWorks is a configuration management service that helps you configure and operate applications in a cloud enterprise by using Puppet or Chef. AWS OpsWorks Stacks and AWS OpsWorks for Chef Automate let you use Chef cookbooks and solutions for configuration management, while OpsWorks for Puppet Enterprise lets you configure a Puppet Enterprise master server in AWS.

OpsWorks for Puppet Enterprise

OpsWorks for Puppet Enterprise lets you create AWS-managed Puppet master servers. A Puppet master server manages nodes in your infrastructure, stores facts about those nodes, and serves as a central repository for your Puppet modules.

OpsWorks for Chef Automate

AWS OpsWorks for Chef Automate lets you create AWS-managed Chef servers that include Chef Automate premium features, and use the Chef DK and other Chef tooling to manage them.

OpsWorks Stacks

AWS OpsWorks Stacks lets you deploy and monitor applications in your stacks. You can create stacks that help you manage cloud resources in specialized groups called layers. A layer represents a set of EC2 instances that serve a particular purpose, such as serving applications or hosting a database server. Layers depend on Chef recipes to handle tasks such as installing packages on instances, deploying apps, and running scripts.

Unlike AWS OpsWorks for Chef Automate, AWS OpsWorks Stacks does not require or create Chef servers; AWS OpsWorks Stacks performs some of the work of a Chef server for you.

Route53

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service. You can use Route 53 to perform three main functions in any combination: domain registration, DNS routing, and health checking. If you choose to use Route 53 for all three functions, perform the steps in this order:

• Register domain names
• Route internet traffic to the resources for your domain
• Check health of your resources

S3

Updates to a single key are atomic. For example, if you PUT to an existing key from one thread and perform a GET on the same key from a second thread concurrently, you will get either the old data or the new data, but never partial or corrupt data.

Object Lock

S3 Object Lock enables you to store objects using a “Write Once Read Many” (WORM) model. S3 Object Lock can help prevent accidental or inappropriate deletion of data. If you overwrite an object (file), it results in a new object version in the bucket. You can always restore the previous version.

Versioning

The versioning state applies to all (never some) of the objects in that bucket. The first time you enable a bucket for versioning, objects in it are thereafter always versioned and given a unique version ID. When you delete an object (file), Amazon S3 inserts a delete marker, which becomes the current object version and you can restore the previous version. Objects stored in your bucket before you set the versioning state have a version ID of null. Those existing objects in your bucket do not change.

S3 Analytics

Storage Class Analysis you can analyze storage access patterns to help you decide when to transition the right data to the right storage class. This new Amazon S3 analytics feature observes data access patterns to help you determine when to transition less frequently accessed STANDARD storage to the STANDARD_IA (IA, for infrequent access) storage class.

S3 Select

Enables applications to retrieve only a subset of data from an object by using simple SQL expressions. By using S3 Select to retrieve only the data needed by your application, you can achieve drastic performance increases – in many cases you can get as much as a 400% improvement.

S3 Inventory

Amazon S3 inventory is one of the tools Amazon S3 provides to help manage your storage. You can use it to audit and report on the replication and encryption status of your objects for business, compliance, and regulatory needs.

Max Size Multipart Upload

S3 objects can be 0 bytes to a max of 5 TB. Largest size that be done in single PUT is 5 GB. In general, when your object size reaches 100 MB, you should consider using multipart uploads instead of uploading the object in a single operation. If you’re uploading over a spotty network, use multipart uploading to increase resiliency to network errors by avoiding upload restarts.

Encryption

Creating your own customer-managed CMK gives you more flexibility and control over the CMK. For example, you can create, rotate, and disable customer-managed CMKs. You can also define access controls and audit the customer-managed CMKs that you use to protect your data.

Server-Side Encryption – Request Amazon S3 to encrypt your object before saving it on disks in its data centers and then decrypt it when you download the objects. (SSE-S3) Using Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3), each object is encrypted with a unique key employing strong multi-factor encryption. As an additional safeguard, it encrypts the key itself with a master key that it regularly rotates.

When you use server-side encryption with AWS KMS (SSE-KMS), you can use the default AWS managed CMK, or you can specify a customer-managed CMK that you have already created. This is similar to SSE-S3. SSE-KMS provides you with an audit trail that shows when your CMK was used and by whom.

Company wants to manage the encryption keys via its custom application and let S3 manage the encryption, therefore you must use Server-Side Encryption with Customer-Provided Keys (SSE-C). Amazon S3 will reject any requests made over HTTP when using SSE-C.

Client-Side Encryption – Encrypt data client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, the encryption keys, and related tools.

Headers for Server Side Encryption

To request SSE-KMS in the object creation REST APIs, use the x-amz-server-side-encryption request header. To specify the ID of the AWS KMS CMK that was used for the object, use x-amz-server-side-encryption-aws-kms-key-id. To enable an S3 Bucket Key, use x-amz-server-side-encryption-bucket-key-enabled.

Pre-signed URL

Share objects with others by creating a pre-signed URL, using their own security credentials, to grant time-limited permission to download the objects. When you create a pre-signed URL for your object, you must provide your security credentials, specify a bucket name, an object key, specify the HTTP method (GET to download the object) and expiration date and time.

Policy Limits

The IAM policies bump up against a size limit (up to 2 kb for users, 5 kb for groups, and 10 kb for roles). S3 supports bucket policies of up 20 kb.

Secrets Manager

Secrets Manager enables you to replace hardcoded credentials in your code, including passwords, with an API call to Secrets Manager to retrieve the secret programmatically. This helps ensure the secret can’t be compromised by someone examining your code, because the secret no longer exists in the code. You can attach AWS Identity and Access Management (IAM) permission policies to your users, groups, and roles that grant or deny access to specific secrets, and restrict management of those secrets.

• Secret name and description
• Rotation or expiration settings
• ARN of the AWS KMS customer master key (CMK) associated with the secret
• Any attached AWS tags

You can configure Secrets Manager to automatically rotate your secrets without user intervention and on a specified schedule. You define and implement rotation with an AWS Lambda function.

• Creates a new version of the secret.
• Stores the secret in Secrets Manager.
• Configures the protected service to use the new version.
• Verifies the new version.
• Marks the new version as production ready.

Simple Notification Service SNS

Amazon SNS allows applications to send time-critical messages to multiple subscribers through a “push” mechanism, eliminating the need to periodically check or “poll” for updates.

SNS can send notifications to SQS standard or FIFO queue as the endpoint; Amazon SNS will enqueue a notification message to the specified queue (which subscribers can then process using SQS APIs such as ReceiveMessage, DeleteMessage, etc.).

• “HTTP”, “HTTPS” – Subscribers specify a URL as part of the subscription registration; notifications will be delivered through an HTTP POST to the specified URL.
• ”Email”, “Email-JSON” – Messages are sent to registered addresses as email. Email-JSON sends notifications as a JSON object, while Email sends text-based email.
• “SQS” – Users can specify an SQS standard queue as the endpoint; Amazon SNS will enqueue a notification message to the specified queue (which subscribers can then process using SQS APIs such as ReceiveMessage, DeleteMessage, etc.).
• “SMS” – Messages are sent to registered phone numbers as SMS text messages.

Mobile Push Notifications

SQS

Amazon SQS is a message queue service used by distributed applications to exchange messages through a polling model, and can be used to decouple sending and receiving components. Amazon SQS provides flexibility for distributed components of applications to send and receive messages without requiring each component to be concurrently available.

When deleting a queue that still has messages in it, those messages will be lost.

When you create a new queue, you must specify a queue name unique for your AWS account and region. There is 80-character queue name quota.

https://sqs.us-east-2.amazonaws.com/123456789012/MyQueue

FIFO Queues

SQS FIFO queues are designed to guarantee that messages are processed exactly once, in the exact order that they are sent. The following key terms can help you better understand the functionality of FIFO queues.

• Message Deduplication ID – The token used for deduplication of sent messages. If a message with a particular message deduplication ID is sent successfully, any messages sent with the same message deduplication ID are accepted successfully but aren’t delivered during the 5-minute deduplication interval.
• Message Group ID – The tag that specifies that a message belongs to a specific message group. Messages that belong to the same message group are always processed one by one, in a strict order relative to the message group.
• Receive Request Attempt ID – The token used for deduplication of ReceiveMessage calls.
• Sequence Number – The large, non-consecutive number that Amazon SQS assigns to each message.

Dead Letter Queues (DLQ)

Dead-letter queues can be used by other queues (source queues) as a target for messages that can’t be processed (consumed) successfully. Dead-letter queues are useful for debugging your application or messaging system because they let you isolate problematic messages to determine why their processing doesn’t succeed.

Visibility Timeout

Amazon SQS uses a visibility timeout to prevent other consumers from receiving and processing the same message. The default visibility timeout for a message is 30 seconds. The minimum is 0 seconds. The maximum is 12 hours.

Delay Queues

Delay queues let you postpone the delivery of new messages to a queue for a number of seconds. The default (minimum) delay for a queue is 0 seconds. The maximum is 15 minutes.

Polling

Amazon SQS provides short polling and long polling to receive messages from a queue. By default, queues use short polling. With short polling, Amazon SQS sends the response right away, even if the query found no messages. With long polling, Amazon SQS sends a response after it collects at least one available message, up to the maximum number of messages specified in the request. Amazon SQS sends an empty response only if the polling wait time expires.

Long polling makes it inexpensive to retrieve messages from your Amazon SQS queue as soon as the messages are available. Long polling helps reduce the cost of using Amazon SQS by eliminating the number of empty responses (when there are no messages available for a ReceiveMessage request) and false empty responses (when messages are available but aren’t included in a response). When the wait time for the ReceiveMessage API action is greater than 0, long polling is in effect. The maximum long polling wait time is 20 seconds.

Polling WaitTimeSeconds

Amazon SQS provides short polling and long polling to receive messages from a queue.

Queue Message Limits

There are no message limits for storing in SQS, but ‘in-flight messages’ do have limits. Make sure to delete messages after you have processed them. There can be a maximum of approximately 120,000 inflight messages (received from a queue by a consumer, but not yet deleted from the queue).

Message Size Limits / Extended Client Library

SQS message max size is 256 KB. To manage large Amazon Simple Queue Service (Amazon SQS) messages, you can use Amazon Simple Storage Service (Amazon S3) and the Amazon SQS Extended Client Library for Java. This is especially useful for storing and consuming messages up to 2 GB.

Receiving / Deleting Messages Limits

After you send messages to a queue, you can receive and delete them. When you request messages from a queue, you can’t specify which messages to retrieve. Instead, you specify the maximum number of messages (up to 10) that you want to retrieve.

Authentication

Only the AWS account owners can access the queues they create. Amazon SQS uses proven cryptographic methods to authenticate your identity, either through the use of your Access Key ID and request signature, or through the use of an X.509 certificate.

Simple Workflow Service (SWF)

The Amazon Simple Workflow Service (Amazon SWF) makes it easy to build applications that coordinate work across distributed components. This is called workflow. When designing a workflow, you analyze your application to identify its component tasks. In Amazon SWF, these tasks are represented by activities. A task represents a logical unit of work that is performed by a component of your application. You implement workers to perform tasks. These workers can run either on cloud infrastructure, such as Amazon Elastic Compute Cloud (Amazon EC2), or on your own premises. You can create tasks that are long-running, or that may fail, time out, or require restarts—or that may complete with varying throughput and latency

Sample Workflow

This workflow starts when a customer places an order. It includes four tasks:

Actors can be workflow starters, deciders, or activity workers. These actors communicate with Amazon SWF through its API. You can develop these actors in any programming language. A decider receives a decision task when the workflow execution starts and each time a state change occurs in the workflow execution. An activity worker is a process or thread that performs the activity tasks that are part of your workflow. The activity task represents one of the tasks that you identified in your application.

Markers

Markers enable you to record information in the workflow execution history that you can use for any custom or scenario-specific purpose.

Quotas

• Maximum open workflow executions – 100,000 per domain
• Maximum workflow execution time – 1 year
• Maximum workflow execution history size – 25,000 events
• Maximum open child workflow executions – 1,000 per workflow execution
• Workflow execution idle time quota – 1 year (constrained by workflow execution time maximum)
• Workflow retention time quota – 90 days

• Maximum pollers per task list – 1,000 per task list
• Maximum task execution time – 1 year (constrained by workflow execution time maximum)
• Maximum time SWF will keep a task in the queue – 1 year (constrained by workflow execution time quota)
• Maximum open activity tasks – 1,000 per workflow execution.
• Maximum open timers – 1,000 per workflow execution
• Maximum input/result data size – 32,768 characters
• Maximum decisions in a decision task response – varies

Step Functions

Step Functions is a serverless orchestration service that lets you combine AWS Lambda functions and other AWS services to build business-critical applications. Step Functions is based on state machines and tasks. A state machine is a workflow. A task is a state in a workflow that represents a single unit of work that another AWS service performs. Each step in a workflow is a state.

Standard vs Express Workflows

When you create a state machine, you must select a Type of either Standard or Express. In both cases, you define your state machine using the Amazon States Language (ASL). Your state machine executions will behave differently, depending on which Type you select. The Type you choose cannot be changed after your state machine has been created.

Standard Workflows are ideal for long-running, durable, and auditable workflows. They can run for up to a year and you can retrieve the full execution history using the Step Functions API, up to 90 days after your execution completes. Standard Workflows employ an at-most-once model, where your tasks and states are never executed more than once unless you have specified Retry behavior in ASL.

With Standard Workflows, the execution state is internally persisted on every state transition. Each execution will be run exactly once. If you attempt to start a Standard Workflow with the same name more than once, only one execution will start. Standard Workflows always run from beginning to end.

Express Workflows are ideal for high-volume, event-processing workloads such as IoT data ingestion, streaming data processing and transformation, and mobile application backends. They can run for up to five minutes. Express Workflows employ an at-least-once model, where there is a possibility that an execution might be run more than once.

Unlike Standard Workflows, Express Workflows have no internally persisted state for executions progress. There is no way to guarantee that one execution will run only once. If you attempt to start an Express Workflow with the same name more than once, each attempt causes an execution to start concurrently, and each runs at least once.

There are two types of Express Workflows that you can choose, Asynchronous Express Workflows and Synchronous Express Workflows.

Transit Gateways

A transit gateway acts as a Regional virtual router for traffic flowing between your virtual private clouds (VPCs) and on-premises networks. It scales elastically based on the volume of network traffic routing through at layer 3, where the packets are sent to a specific next-hop attachment, based on their destination IP addresses.

X-Ray

AWS X-Ray is a service that collects data about requests that your application serves, and provides tools you can use to view, filter, and gain insights into that data to identify issues and opportunities for optimization. For any traced request to your application, you can see detailed information not only about the request and response, but also about calls that your application makes to downstream AWS resources, microservices, databases and HTTP web APIs.

The X-Ray SDK provides:

Concepts

AWS X-Ray receives data from services as segments. X-Ray then groups segments that have a common request into traces. X-Ray processes the traces to generate a service graph that provides a visual representation of your application.

• Segments
• Subsegments
• Service graph
• Traces
• Sampling
• Tracing header
• Filter expressions
• Groups
• Annotations and metadata
• Errors, faults, and exceptions

Annotations are simple key-value pairs that are indexed for use with filter expressions. Use annotations to record data that you want to use to group traces in the console, or when calling the GetTraceSummaries API.

Metadata are key-value pairs with values of any type, including objects and lists, but that is not indexed. Use metadata to record data you want to store in the trace but don’t need to use for searching traces.

The computing resources running your application logic send data about their work as segments. A segment provides the resource’s name, details about the request, and details about the work done.

To ensure efficient tracing and provide a representative sample of the requests that your application serves, the X-Ray SDK applies a sampling algorithm to determine which requests get traced. By default, the X-Ray SDK records the first request each second, and five percent of any additional requests.

X-Ray Sampling

By customizing sampling rules, you can control the amount of data that you record, and modify sampling behavior on the fly without modifying or redeploying your code. Sampling rules tell the X-Ray SDK how many requests to record for a set of criteria.

X-Ray Daemon

The AWS X-Ray daemon is a software application that listens for traffic on UDP port 2000, gathers raw segment data, and relays it to the AWS X-Ray API. The daemon logs could help with figuring out the problem.

X-Ray provides a Docker container image that you can deploy alongside your application. As we are using AWS Fargate, we do not have control over the underlying EC2 instance and thus we can’t deploy the agent on the EC2 instance or run an X-Ray agent container as a daemon set (only available for ECS classic). For Fargate, we can only provide IAM roles to tasks, which is also the best security practice should we use EC2 instances.

X-Ray cross accounts