AWS Auto Scaling

 

• Configure automatic scaling for the AWS resources quickly through a scaling plan that uses dynamic scaling and predictive scaling.
• Optimize for availability, for cost, or a balance of both.
• Scaling in means decreasing the size of a group while scaling out means increasing the size of a group.
• Useful for
  • Cyclical traffic such as high use of resources during regular business hours and low use of resources overnight
  • On and off traffic patterns, such as batch processing, testing, or periodic analysis
  • Variable traffic patterns, such as software for marketing campaigns with periods of spiky growth
• It is a region specific service. 

Features

• Launch or terminate EC2 instances in an Auto Scaling group.
• Launch or terminate instances from an EC2 Spot Fleet request, or automatically replace instances that get interrupted for price or capacity reasons.
• Adjust the ECS service desired count up or down in response to load variations.
• Enable a DynamoDB table or a global secondary index to increase or decrease its provisioned read and write capacity to handle increases in traffic without throttling.
• Dynamically adjust the number of Aurora read replicas provisioned for an Aurora DB cluster to handle changes in active connections or workload.
• Use Dynamic Scaling to add and remove capacity for resources to maintain resource utilization at the specified target value.
• Use Predictive Scaling to forecast your future load demands by analyzing your historical records for a metric. It also allows you to schedule scaling actions that proactively add and remove resource capacity to reflect the load forecast, and control maximum capacity behavior. Only available for EC2 Auto Scaling groups.
• AWS Auto Scaling scans your environment and automatically discovers the scalable cloud resources underlying your application, so you don’t have to manually identify these resources one by one through individual service interfaces.
• You can suspend and resume any of your AWS Application Auto Scaling actions.

Amazon EC2 Auto Scaling

• Ensuring you have the correct number of EC2 instances available to handle your application load using Auto Scaling Groups.
• An Auto Scaling group contains a collection of EC2 instances that share similar characteristics and are treated as a logical grouping for the purposes of instance scaling and management.
• You specify the minimum, maximum and desired number of instances in each Auto Scaling group.
• Key Components

Groups	Your EC2 instances are organized into groups so that they are treated as a logical unit for scaling and management. When you create a group, you can specify its minimum, maximum, and desired number of EC2 instances.
Launch configurations	Your group uses a launch configuration as a template for its EC2 instances. When you create a launch configuration, you can specify information such as the AMI ID, instance type, key pair, security groups, and block device mapping for your instances.
Scaling options	How to scale your Auto Scaling groups.

• Auto Scaling Lifecycle

• You can add a lifecycle hook to your Auto Scaling group to perform custom actions when instances launch or terminate.
• Scaling Options
  • Scale to maintain current instance levels at all times
  • Manual Scaling
  • Scale based on a schedule
  • Scale based on a demand
• Scaling Policy Types
  • Target tracking scaling—Increase or decrease the current capacity of the group based on a target value for a specific metric.
  • Step scaling—Increase or decrease the current capacity of the group based on a set of scaling adjustments, known as step adjustments, that vary based on the size of the alarm breach.
  • Simple scaling—Increase or decrease the current capacity of the group based on a single scaling adjustment.
• The cooldown period is a configurable setting that helps ensure to not launch or terminate additional instances before previous scaling activities take effect.
  • EC2 Auto Scaling supports cooldown periods when using simple scaling policies, but not when using target tracking policies, step scaling policies, or scheduled scaling.
• Amazon EC2 Auto Scaling marks an instance as unhealthy if the instance is in a state other than running, the system status is impaired, or Elastic Load Balancing reports that the instance failed the health checks.
• Termination of Instances
  • When you configure automatic scale in, you must decide which instances should terminate first and set up a termination policy. You can also use instance protection to prevent specific instances from being terminated during automatic scale in.
  • Default Termination Policy

• Custom Termination Policies
  • OldestInstance – Terminate the oldest instance in the group.
  • NewestInstance – Terminate the newest instance in the group.
  • OldestLaunchConfiguration – Terminate instances that have the oldest launch configuration.
  • ClosestToNextInstanceHour – Terminate instances that are closest to the next billing hour.
• You can create launch templates that specifies instance configuration information when you launch EC2 instances, and allows you to have multiple versions of a template.
• A launch configuration is an instance configuration template that an Auto Scaling group uses to launch EC2 instances, and you specify information for the instances.
  • You can specify your launch configuration with multiple Auto Scaling groups.
  • You can only specify one launch configuration for an Auto Scaling group at a time, and you can’t modify a launch configuration after you’ve created it.
  • When you create a VPC, by default its tenancy attribute is set to default. You can launch instances with a tenancy value of dedicated so that they run as single-tenancy instances. Otherwise, they run as shared-tenancy instances by default.
  • If you set the tenancy attribute of a VPC to dedicated, all instances launched in the VPC run as single-tenancy instances.
  • When you create a launch configuration, the default value for the instance placement tenancy is null and the instance tenancy is controlled by the tenancy attribute of the VPC.

Launch Configuration Tenancy	VPC Tenancy = default	VPC Tenancy = dedicated
not specified	shared-tenancy instance	Dedicated Instance
default	shared-tenancy instance	Dedicated Instance
dedicated	Dedicated Instance	Dedicated Instance

• • If you are launching the instances in your Auto Scaling group in EC2-Classic, you can link them to a VPC using ClassicLink.

Application Auto Scaling

• • Allows you to configure automatic scaling for the following resources:
    • Amazon ECS services
    • Spot Fleet requests
    • Amazon EMR clusters
    • AppStream 2.0 fleets
    • DynamoDB tables and global secondary indexes
    • Aurora replicas
    • Amazon SageMaker endpoint variants
    • Custom resources provided by your own applications or services.
  • Features
    • Target tracking scaling—Scale a resource based on a target value for a specific CloudWatch metric.
    • Step scaling— Scale a resource based on a set of scaling adjustments that vary based on the size of the alarm breach.
    • Scheduled scaling—Scale a resource based on the date and time. The timezone can either be in UTC or in your local timezone.
  • Target tracking scaling
    • You can have multiple target tracking scaling policies for a scalable target, provided that each of them uses a different metric.
    • You can also optionally disable the scale-in portion of a target tracking scaling policy.
  • Step scaling
    • Increase or decrease the current capacity of a scalable target based on a set of scaling adjustments, known as step adjustments, that vary based on the size of the alarm breach.
  • Scheduled scaling
    • Scale your application in response to predictable load changes by creating scheduled actions, which tell Application Auto Scaling to perform scaling activities at specific times.
  • The scale out cooldown period is the amount of time, in seconds, after a scale out activity completes before another scale out activity can start.
  • The scale in cooldown period is the amount of time, in seconds, after a scale in activity completes before another scale in activity can start.
• You can attach one or more classic ELBs to your existing Auto Scaling Groups. The ELBs must be in the same region.
• Auto Scaling rebalances by launching new EC2 instances in the AZs that have fewer instances first, only then will it start terminating instances in AZs that had more instances

Monitoring

• • Health checks – identifies any instances that are unhealthy
    • Amazon EC2 status checks (default)
    • Elastic Load Balancing health checks
    • Custom health checks.
  • Auto scaling does not perform health checks on instances in the standby state. Standby state can be used for performing updates/changes/troubleshooting without health checks being performed or replacement instances being launched.
  • CloudWatch metrics – enables you to retrieve statistics about Auto Scaling-published data points as an ordered set of time-series data, known as metrics. You can use these metrics to verify that your system is performing as expected.
  • CloudWatch Events – Auto Scaling can submit events to CloudWatch Events when your Auto Scaling groups launch or terminate instances, or when a lifecycle action occurs.
  • SNS notifications – Auto Scaling can send Amazon SNS notifications when your Auto Scaling groups launch or terminate instances.
  • CloudTrail logs – enables you to keep track of the calls made to the Auto Scaling API by or on behalf of your AWS account, and stores the information in log files in an S3 bucket that you specify.

Security

• • Use IAM to help secure your resources by controlling who can perform AWS Auto Scaling actions.
  • By default, a brand new IAM user has NO permissions to do anything. To grant permissions to call Auto Scaling actions, you attach an IAM policy to the IAM users or groups that require the permissions it grants.

Amazon CloudWatch

 

• Monitoring tool for your AWS resources and applications.
• Display metrics and create alarms that watch the metrics and send notifications or automatically make changes to the resources you are monitoring when a threshold is breached.
  

• CloudWatch is basically a metrics repository. An AWS service, such as Amazon EC2, puts metrics into the repository and you retrieve statistics based on those metrics. If you put your own custom metrics into the repository, you can retrieve statistics on these metrics as well.
• CloudWatch does not aggregate data across regions. Therefore, metrics are completely separate between regions.

CloudWatch Concepts

• • Namespaces – a container for CloudWatch metrics.

    • There is no default namespace.
    • The AWS namespaces use the following naming convention: AWS/service.

  • Metrics – represents a time-ordered set of data points that are published to CloudWatch.

    • Exists only in the region in which they are created.
    • Cannot be deleted, but they automatically expire after 15 months if no new data is published to them.
    • As new data points come in, data older than 15 months is dropped.
    • Each metric data point must be marked with a timestamp. The timestamp can be up to two weeks in the past and up to two hours into the future. If you do not provide a timestamp, CloudWatch creates a timestamp for you based on the time the data point was received.
    • By default, several services provide free metrics for resources. You can also enable detailed monitoring, or publish your own application metrics.
    • Metric math enables you to query multiple CloudWatch metrics and use math expressions to create new time series based on these metrics.
    • Important note for EC2 metrics: CloudWatch does not collect memory utilization and disk space usage metrics right from the get go. You need to install CloudWatch Agent in your instances first to retrieve these metrics.

  • Dimensions – a name/value pair that uniquely identifies a metric.

    • You can assign up to 10 dimensions to a metric.
    • Whenever you add a unique dimension to one of your metrics, you are creating a new variation of that metric.

  • Statistics – metric data aggregations over specified periods of time.

• • • Each statistic has a unit of measure. Metric data points that specify a unit of measure are aggregated separately.
    • You can specify a unit when you create a custom metric. If you do not specify a unit, CloudWatch uses None as the unit.
    • A period is the length of time associated with a specific CloudWatch statistic. The default value is 60 seconds.
    • CloudWatch aggregates statistics according to the period length that you specify when retrieving statistics.
    • For large datasets, you can insert a pre-aggregated dataset called a statistic set.

Statistic	Description
Minimum	The lowest value observed during the specified period. You can use this value to determine low volumes of activity for your application.
Maximum	The highest value observed during the specified period. You can use this value to determine high volumes of activity for your application.
Sum	All values submitted for the matching metric added together. Useful for determining the total volume of a metric.
Average	The value of Sum / SampleCount during the specified period. By comparing this statistic with the Minimum and Maximum, you can determine the full scope of a metric and how close the average use is to the Minimum and Maximum. This comparison helps you to know when to increase or decrease your resources as needed.
SampleCount	The count (number) of data points used for the statistical calculation.
pNN.NN	The value of the specified percentile. You can specify any percentile, using up to two decimal places (for example, p95.45). Percentile statistics are not available for metrics that include any negative values.

• Percentiles – indicates the relative standing of a value in a dataset. Percentiles help you get a better understanding of the distribution of your metric data.

• Alarms – watches a single metric over a specified time period, and performs one or more specified actions, based on the value of the metric relative to a threshold over time.

  • You can create an alarm for monitoring CPU usage and load balancer latency, for managing instances, and for billing alarms.
  • When an alarm is on a dashboard, it turns red when it is in the ALARM state.
  • Alarms invoke actions for sustained state changes only.
  • Alarm States
    • OK—The metric or expression is within the defined threshold.
    • ALARM—The metric or expression is outside of the defined threshold.
    • INSUFFICIENT_DATA—The alarm has just started, the metric is not available, or not enough data is available for the metric to determine the alarm state.
  • You can also monitor your estimated AWS charges by using Amazon CloudWatch Alarms. However, take note that you can only track the estimated AWS charges in CloudWatch and not the actual utilization of your resources. Remember that you can only set coverage targets for your reserved EC2 instances in AWS Budgets or Cost Explorer, but not in CloudWatch.

• • When you create an alarm, you specify three settings:
    • Period is the length of time to evaluate the metric or expression to create each individual data point for an alarm. It is expressed in seconds.
    • Evaluation Period is the number of the most recent periods, or data points, to evaluate when determining alarm state.
    • Datapoints to Alarm is the number of data points within the evaluation period that must be breaching to cause the alarm to go to the ALARM state. The breaching data points do not have to be consecutive, they just must all be within the last number of data points equal to Evaluation Period.

• • • For each alarm, you can specify CloudWatch to treat missing data points as any of the following:
      • missing—the alarm does not consider missing data points when evaluating whether to change state (default)
      • notBreaching—missing data points are treated as being within the threshold
      • breaching—missing data points are treated as breaching the threshold
      • ignore—the current alarm state is maintained
  • You can now create tags in CloudWatch alarms that let you define policy controls for your AWS resources. This enables you to create resource level policies for your alarms.

CloudWatch Dashboard

• • Customizable home pages in the CloudWatch console that you can use to monitor your resources in a single view, even those spread across different regions.
  • There is no limit on the number of CloudWatch dashboards you can create.
  • All dashboards are global, not region-specific.
  • You can add, remove, resize, move, edit or rename a graph. You can metrics manually in a graph.
  • You can share your dashboards with users who do not have direct access to your AWS account via three ways:
    • Share a single dashboard and designate specific email addresses and passwords of the people who can view the dashboard.
    • Share a single dashboard publicly, so that anyone who has the link can view the dashboard.
    • Share all the CloudWatch dashboards in your account and specify a third-party SSO provider for dashboard access. All users who are members of this SSO provider’s list can access the dashboards in the account. To enable this, you integrate the SSO provider with Amazon Cognito. 

CloudWatch Events (Amazon EventBridge)

• • Deliver near real-time stream of system events that describe changes in AWS resources.
  • Events respond to these operational changes and take corrective action as necessary, by sending messages to respond to the environment, activating functions, making changes, and capturing state information.
  • Concepts
    • Events – indicates a change in your AWS environment.
    • Targets – processes events.
    • Rules – matches incoming events and routes them to targets for processing.
  • Amazon EventBridge is a service that builds upon the CloudWatch Events service API. Both Amazon EventBridge and CloudWatch Events use the same underlying infrastructure. You can still continue managing events through CloudWatch Events but the preferred way is to manage events via Amazon EventBridge.
  • Amazon EventBridge extends the capabilities of CloudWatch Events by enabling customers to connect data from their own apps and third-party SaaS apps, making it easier to connect applications.

CloudWatch Logs

• • Features
    • Monitor logs from EC2 instances in real-time
    • Monitor CloudTrail logged events
    • By default, logs are kept indefinitely and never expire
    • Archive log data
    • Log Route 53 DNS queries
  • CloudWatch Logs Insights enables you to interactively search and analyze your log data in CloudWatch Logs using queries.
  • CloudWatch Vended logs are logs that are natively published by AWS services on behalf of the customer. VPC Flow logs is the first Vended log type that will benefit from this tiered model.
  • After the CloudWatch Logs agent begins publishing log data to Amazon CloudWatch, you can search and filter the log data by creating one or more metric filters. Metric filters define the terms and patterns to look for in log data as it is sent to CloudWatch Logs.
  • Filters do not retroactively filter data. Filters only publish the metric data points for events that happen after the filter was created. Filtered results return the first 50 lines, which will not be displayed if the timestamp on the filtered results is earlier than the metric creation time.
  • Metric Filter Concepts
    • filter pattern – you use the pattern to specify what to look for in the log file.
    • metric name – the name of the CloudWatch metric to which the monitored log information should be published.
    • metric namespace – the destination namespace of the new CloudWatch metric.
    • metric value – the numerical value to publish to the metric each time a matching log is found.
    • default value – the value reported to the metric filter during a period when no matching logs are found. By setting this to 0, you ensure that data is reported during every period.
    • You can create two subscription filters with different filter patterns on a single log group.

CloudWatch Agent

• • Collect more logs and system-level metrics from EC2 instances and your on-premises servers.
  • Needs to be installed.
• Cloudwatch Metric Streams
  • Amazon CloudWatch Metric Streams lets you create a continuous, near real-time stream of metrics to a destination of your choice.
  • You can use Metric Streams to send metrics to Datadog, New Relic, Splunk, Dynatrace, Sumo Logic, and S3.

Authentication and Access Control

• • Use IAM users or roles for authenticating who can access
  • Use Dashboard Permissions, IAM identity-based policies, and service-linked roles for managing access control.
  • A permissions policy describes who has access to what.
    • Identity-Based Policies
    • Resource-Based Policies
  • There are no CloudWatch Amazon Resource Names (ARNs) for you to use in an IAM policy. Use an * (asterisk) instead as the resource when writing a policy to control access to CloudWatch actions.

Pricing

• • You are charged for the number of metrics you have per month
  • You are charged per 1000 metrics requested using CloudWatch API calls
  • You are charged per dashboard per month
  • You are charged per alarm metric (Standard Resolution and High Resolution)
  • You are charged per GB of collected, archived and analyzed log data
  • There is no Data Transfer IN charge, only Data Transfer Out.
  • You are charged per million custom events and per million cross-account events
  • Logs Insights is priced per query and charges based on the amount of ingested log data scanned by the query.

AWS WAF

 

• A web application firewall that helps protect web applications from attacks by allowing you to configure rules that allow, block, or monitor (count) web requests based on conditions that you define.
• These conditions include:

• • IP addresses
  • HTTP headers
  • HTTP body
  • URI strings
  • SQL injection
  • cross-site scripting.

Features

• WAF lets you create rules to filter web traffic based on conditions that include IP addresses, HTTP headers and body, or custom URIs.
• You can also create rules that block common web exploits like SQL injection and cross site scripting.
• For application layer attacks, you can use WAF to respond to incidents. You can set up proactive rules like Rate Based Blacklisting to automatically block bad traffic, or respond immediately to incidents as they happen.
• WAF provides real-time metrics and captures raw requests that include details about IP addresses, geo locations, URIs, User-Agent and Referers.
• AWS WAF can parse request body JSON content to inspect specific keys or values in the JSON content with WAF rules. This helps you protect your APIs by checking for valid JSON structure, inspecting the JSON content for common threats against your application, and reducing false positives by inspecting only the keys or values in the JSON content.
• AWS WAF Security Automations is a solution that automatically deploys a single web access control list (web ACL) with a set of AWS WAF rules designed to filter common web-based attacks. The solution supports log analysis using Amazon Athena and AWS WAF full logs.

Conditions, Rules, and Web ACLs

• You define your conditions, combine your conditions into rules, and combine the rules into a web ACL.
• Conditions define the basic characteristics that you want WAF to watch for in web requests.
• You combine conditions into rules to precisely target the requests that you want to allow, block, or count. WAF provides two types of rules:
  • Regular rules – use only conditions to target specific requests.
  • Rate-based rules – are similar to regular rules, with a rate limit. Rate-based rules count the requests that arrive from a specified IP address every five minutes. The rule can trigger an action if the number of requests exceed the rate limit.
• WAF Managed Rules are an easy way to deploy pre-configured rules to protect your applications common threats like application vulnerabilities. All Managed Rules are automatically updated by AWS Marketplace security Sellers.
• After you combine your conditions into rules, you combine the rules into a web ACL. This is where you define an action for each rule—allow, block, or count—and a default action, which determines whether to allow or block a request that doesn’t match all the conditions in any of the rules in the web ACL.
• You can insert HTTP headers to a user request when WAF allows the request to reach your application. You can use the custom HTTP headers to validate the requests made to your application passed through WAF, and configure your application to only allow requests that contain the custom header values that you specify. You can also insert headers so your application can process the request differently based on the presence of the header, or log the header in your application logs for reporting and analytics.
• WAF lets you configure the HTTP status code and the response body returned to the user when a request is blocked.

Pricing

• WAF charges based on the number of web access control lists (web ACLs) that you create, the number of rules that you add per web ACL, and the number of web requests that you receive.

AWS Shield

 

• A managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS.

Shield Tiers and Features

• Standard
  • All AWS customers benefit from the automatic protections of Shield Standard.
  • Shield Standard provides always-on network flow monitoring which inspects incoming traffic to AWS and detect malicious traffic in real-time.
  • Uses several techniques like deterministic packet filtering, and priority based traffic shaping to automatically mitigate attacks without impact to your applications.
  • When you use Shield Standard with CloudFront and Route 53, you receive comprehensive availability protection against all known infrastructure attacks.
  • You can also view all the events detected and mitigated by AWS Shield in your account.
• Advanced
  • Shield Advanced provides enhanced detection, inspecting network flows and also monitoring application layer traffic to your Elastic IP address, Elastic Load Balancing, CloudFront, or Route 53 resources.
  • It handles the majority of DDoS protection and mitigation responsibilities for layer 3, layer 4, and layer 7 attacks.
  • You have 24×7 access to the AWS DDoS Response Team. To contact the DDoS Response Team, customers will need the Enterprise or Business Support levels of AWS Premium Support.
  • It automatically provides additional mitigation capacity to protect against larger DDoS attacks. The DDoS Response Team also applies manual mitigations for more complex and sophisticated DDoS attacks.
  • It gives you complete visibility into DDoS attacks with near real-time notification via CloudWatch and detailed diagnostics on the “AWS WAF and AWS Shield” Management Console.
  • Shield Advanced comes with “DDoS cost protection”, a safeguard from scaling charges as a result of a DDoS attack that cause usage spikes on your AWS services. It does so by providing service credits for charges due to usage spikes.
  • It is available globally on all CloudFront and Route 53 edge locations. 
  • With Shield Advanced you will be able to see the history of all incidents in the trailing 13 months.

Other Additional Features

• You can scan Amazon S3 buckets across multiple AWS accounts, and perform scoping of scans by object prefix.
• An estimation of the costs of these job runs is sent to you for review before you run them.
• Once a job is submitted, findings are generated in the Amazon Macie console and sent out through Amazon EventBridge where sensitive data location information is included in the findings. This allows for identification of sensitive data within objects using detail such as line numbers, page numbers, record index, or column and row numbers.

Pricing

• Shield Standard provides protection at no additional charge.
• Shield Advanced, however, is a paid service. It requires a 1-year subscription commitment and charges a monthly fee, plus a usage fee based on data transfer out from CloudFront, ELB, EC2, and AWS Global Accelerator.

AWS Security Hub

 

• AWS Security Hub provides a comprehensive view of your security state within AWS and your compliance with security industry standards and best practices.

Features

• You now have a single place that aggregates, organizes, and prioritizes your security alerts, or findings, across multiple accounts, AWS partner tools, and AWS services such as Amazon GuardDuty, Amazon Inspector, Amazon Macie, AWS IAM Access Analyzer, AWS Firewall Manager, and AWS Audit Manager.
• AWS Security Hub works with AWS Organizations to simplify security posture management across all of your existing and future AWS accounts in an organization.
• You can run automated, continuous account-level configuration and compliance checks based on industry standards and best practices, such as the Center for Internet Security (CIS) AWS Foundations Benchmark. These checks provide a compliance score and identify specific accounts and resources that require attention.
• AWS Security Hub compliance checks also leverage configuration items recorded by AWS Config.
• Integrated dashboards consolidate your security findings across accounts to show you their current security and compliance status.
• You can send security findings to ticketing, chat, email, or automated remediation systems through integration with Amazon CloudWatch Events.
• All findings are stored for at least 90 days within AWS Security Hub.

How It Works

• Security Hub receives and processes only those findings from the same Region where you enabled Security Hub in your account.

Concepts

• AWS Security Finding Format – A standardized format for the contents of findings that Security Hub aggregates or generates. 
• Control – A safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements. A security standard consists of controls.
• Custom action – A Security Hub mechanism for sending selected findings to CloudWatch Events. 
• Finding – The observable record of a compliance check or security-related detection.
• Insight – A collection of related findings defined by an aggregation statement and optional filters. An insight identifies a security area that requires attention and intervention.
• Compliance standards – Sets of controls that are based on regulatory requirements or best practices.
• You can disable specific compliance controls that are not relevant to your workloads.
• Compliance standard vs. Control vs. Compliance check
  • A compliance standard is a collection of controls based on regulatory frameworks or industry best practices. Security Hub conducts automated compliance checks against controls. Each compliance check consists of an evaluation of a rule against a single resource. A single control may involve multiple resources and a compliance check is performed against each resource.
  • AWS Security Hub uses a service-linked role that includes the permissions and trust policy that Security Hub requires to detect and aggregate findings, and to configure the requisite AWS Config infrastructure needed to run compliance checks. In order for Security Hub to run compliance checks in an account, you must have AWS Config enabled in that account.

Pricing

• AWS Security Hub is priced based on the quantity of compliance checks and the quantity of finding ingestion events.
• Pricing is on a monthly per account, per region basis.

AWS Secrets Manager

 

• A secret management service that enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle.

Features

• • AWS Secrets Manager encrypts secrets at rest using encryption keys that you own and store in AWS Key Management Service [customer managed keys]. When you retrieve a secret, Secrets Manager decrypts the secret and transmits it securely over TLS to your local environment.
  • You can rotate secrets on a schedule or on demand by using the Secrets Manager console, AWS SDK, or AWS CLI.
  • Secrets Manager natively supports rotating credentials for databases hosted on Amazon RDS and Amazon DocumentDB and clusters hosted on Amazon Redshift.
  • You can extend Secrets Manager to rotate other secrets, such as credentials for Oracle databases hosted on EC2 or OAuth refresh tokens, by using custom AWS Lambda functions.
• A secret consists of a set of credentials (user name and password), and the connection details used to access a secured service.
• A secret also contains metadata which include:
  • Basic information includes the name of the secret, a description, and the Amazon Resource Name (ARN) to serve as a unique identifier.
  • The ARN of the AWS KMS key Secrets Manager uses to encrypt and decrypt the protected text in the secret. If you don’t provide this information, Secrets Manager uses the default AWS KMS key for the account.
  • Information about how frequently to rotate the key and what Lambda function to use to perform the rotation.
  • A user-provided set of tags. You can attach tags as key-value pairs to AWS resources for organizing, logical grouping, and cost allocation.
• A secret can contain versions:
  • Although you typically only have one version of the secret active at a time, multiple versions can exist while you rotate a secret on the database or service. Whenever you change the secret, Secrets Manager creates a new version.
  • Each version holds a copy of the encrypted secret value.
  • Each version can have one or more staging labels attached identifying the stage of the secret rotation cycle.
• Supported Secrets
  • Database credentials, on-premises resource credentials, SaaS application credentials, third-party API keys, and SSH keys. 
  • You can also store JSON documents.
• To retrieve secrets, you simply replace secrets in plain text in your applications with code to pull in those secrets programmatically using the Secrets Manager APIs.
• Secrets can be cached on the client side, and updated only during a secret rotation.
• During the secret rotation process, Secrets Manager tracks the older credentials, as well as the new credentials you want to start using, until the rotation completes. It tracks these different versions by using staging labels.

How Secret Rotation Works

• • The rotation function contacts the secured service authentication system and creates a new set of credentials to access the database. Secrets Manager stores these new credentials as the secret text in a new version of the secret with the AWSPENDING staging label attached.
  • The rotation function then tests the AWSPENDING version of the secret to ensure that the credentials work, and grants the required level of access to the secured service.
  • If the tests succeed, the rotation function then moves the label AWSCURRENT to the new version to mark it as the default version. Then, all of the clients start using this version of the secret instead of the old version. The function also assigns the label AWSPREVIOUS to the old version. The version that had AWSPREVIOUS staging label now has no label, and therefore deprecated.
• Network Setup for Secret Rotation
  • When rotating secrets on natively supported services, Secrets Manager uses CloudFormation to build the rotation function and configure the network connection between the two.
    • If your protected database service runs in a VPC and is not publicly accessible, then the CloudFormation template configures the Lambda rotation function to run in the same VPC. The rotation function can communicate with the protected service directly within the VPC.
    • If you run your protected service as a publicly accessible resource, in a VPC or not, then the CloudFormation template configures the Lambda rotation function not to run in a VPC. The Lambda rotation function communicates with the protected service through the publicly accessible connection point.
  • By default, the Secrets Manager endpoints run on the public Internet. If you run your Lambda rotation function and protected database or service in a VPC, then you must perform one of the following steps:
    • Add a NAT gateway to your VPC. This enables traffic that originates in your VPC to reach the public Secrets Manager endpoint. 
    • Configure Secrets Manager service endpoints directly within your VPC. This configures your VPC to intercept any request addressed to the public regional endpoint, and redirect the request to the private service endpoint running within your VPC.
• You can create two secrets that have different permissions
  • User Secret – can be used to connect to linked services, but it cannot be rotated. The user will have to wait for the master secret to be rotated and propagated for it to change.
  • Master Secret – has sufficient permissions to rotate secrets of linked services. This scenario is typically used when you have users that are actively using the old secret, and you do not want to break operations after you rotate the secret. You can have your users  update their clients first before using the newly rotated credentials.
• Secrets Manager lets you easily copy your secrets to multiple AWS Regions, which includes the primary secret and the associated metadata such as tags, resource policies and secret updates such as rotation.

Security

• • By default, Secrets Manager does not write or cache the secret to persistent storage.
  • By default, Secrets Manager only accepts requests from hosts that use the open standard Transport Layer Security (TLS) and Perfect Forward Secrecy.
  • You can control access to the secret using AWS Identity and Access Management (IAM) policies. 
  • You can tag secrets individually and apply tag-based access controls.
  • You can configure VPC endpoints to keep traffic between your VPC and Secrets Manager within the AWS network.
  • Secrets Manager does not immediately delete secrets. Instead, Secrets Manager immediately makes the secrets inaccessible and scheduled for deletion after a recovery window of a minimum of seven days. Until the recovery window ends, you can recover a secret you previously deleted. 
  • By using the CLI, you can delete a secret without a recovery window.

Compliance

• • Secrets Manager is HIPAA, PCI DSS and ISO, SOC, FedRAMP, DoD SRG, IRAP, and OSPAR compliant.

Pricing

• • You pay based on the number of secrets stored and API calls made per month.

AWS Resource Access Manager

 

• A service that enables you to easily and securely share AWS resources with any AWS account or, if you are part of AWS Organizations, with Organizational Units (OUs) or your entire Organization. If you share resources with accounts that are outside of your Organization, then those accounts will receive an invitation to the Resource Share and can start using the shared resources upon accepting the invitation.
  • Only the master account can enable sharing with AWS Organizations.
  • The organization must be enabled for all features.
• RAM eliminates the need to create duplicate resources in multiple accounts. You can create resources centrally in a multi-account environment, and use RAM to share those resources across accounts in three simple steps: 

• 1. Create a Resource Share
  2. Specify resources
  3. Specify accounts

• You can stop sharing a resource by deleting the share in AWS RAM.
• Services you can share with AWS RAM

Service	Resource
Amazon Aurora	DB Clusters
AWS CodeBuild	Projects,Report Groups
Amazon EC2	Capacity Reservations, Dedicated Hosts, Subnets, Traffic mirror targets, Transit gateways
Amazon EC2 Image Builder	Components, Images (AMI), Image recipes
AWS License Manager	License configurations
AWS Resource Groups	Resource groups
Amazon Route 53	Forwarding rules

• Security
  • Use IAM policies to secure who can access resources that you shared or received from another account. 
• Pricing
  • There is no additional charge for using AWS RAM.