Guidance

• • The AWS Encryption SDK for C, the AWS Encryption SDK for JavaScript, the AWS Encryption SDK for Java, and the AWS Encryption SDK for .NET use keyrings to perform envelope encryption. Keyrings generate, encrypt, and decrypt data keys. Keyrings determine the source of the unique data keys that protect each message, and the wrapping keys that encrypt that data key. You specify a keyring when encrypting and the same or a different keyring when decrypting. You can use the keyrings that the SDK provides or write your own compatible custom keyrings.
• How keyrings work

  • When you encrypt data, the AWS Encryption SDK asks the keyring for encryption materials. The keyring returns a plaintext data key and a copy of the data key that's encrypted by each of the wrapping keys in the keyring. The AWS Encryption SDK uses the plaintext key to encrypt the data, and then destroys the plaintext data key. Then, the AWS Encryption SDK returns an encrypted message that includes the encrypted data keys and the encrypted data.

  
• • How keyrings workWhen you decrypt data, you can use the same keyring that you used to encrypt the data, or a different one. To decrypt the data, a decryption keyring must include (or have access to) at least one wrapping key in the encryption keyring.
• Keyring Decryption:

  • The AWS Encryption SDK passes the encrypted data keys from the encrypted message to the keyring, and asks the keyring to decrypt any one of them. The keyring uses its wrapping keys to decrypt one of the encrypted data keys and returns a plaintext data key. The AWS Encryption SDK uses the plaintext data key to decrypt the data. If none of the wrapping keys in the keyring can decrypt any of the encrypted data keys, the decrypt operation fails.
• You can use a single keyring or also combine keyrings of the same type or a different type into a multi-keyring. When you encrypt data, the multi-keyring returns a copy of the data key encrypted by all of the wrapping keys in all of the keyrings that comprise the multi-keyring. You can decrypt the data using a keyring with any one of the wrapping keys in the multi-keyring.
• VPC sharing allows customers to share subnets with other AWS accounts within the same AWS Organization. This is a very powerful concept that allows for a number of benefits:

  • Separation of duties: centrally controlled VPC structure, routing, IP address allocation.
  • Application owners continue to own resources, accounts, and security groups.
  • VPC sharing participants can reference security group IDs of each other.
  • Efficiencies: higher density in subnets, efficient use of VPNs and AWS Direct Connect.
• VPC sharing allows customers to share subnets with other AWS accounts within the same AWS Organization. This is a very powerful concept that allows for a number of benefits:

  • Hard limits can be avoided, for example, 50 VIFs per AWS Direct Connect connection through simplified network architecture.
  • Costs can be optimized through reuse of NAT gateways, VPC interface endpoints, and intra-Availability Zone traffic.
• RAM

  • VPC owners are responsible for creating, managing and deleting all VPC-level resources including subnets, route tables, network ACLs, peering connections, VPC endpoints, AWS PrivateLink endpoints, internet gateways, NAT gateways, virtual private gateways, and transit gateway attachments. A VPC owner cannot delete, modify or forcefully eject a participant’s resources. VPC owners can view the details for all the network interfaces, and the security groups that are attached to the participant resources in order to facilitate troubleshooting, and auditing.
• RAM:

  • VPC participants are responsible for the creation, management, and deletion of their resources. Participants cannot view or modify resources that belong to other participant accounts. They can view the details of the route tables, and network ACLs that are attached to the subnets shared with them. However, they cannot modify VPC-level resources including route tables, network ACLs, or subnets. Participants can reference security groups that belong to other participants or the owner using the security group ID.
• RAM:

  • VPC owners can create flow log subscriptions at the VPC, subnet, or ENI level for traffic monitoring or troubleshooting.
  • Participants can only create flow log subscriptions for the interfaces that they own.
• Things to know

  • VPC sharing is only available within the same AWS Organization.
  • Sharing of default VPCs/subnets is not possible.
  • Participants can’t launch resources using security groups that are owned by other participants or the owner.
  • Participants can’t launch resources using the default security group for the VPC because it belongs to the owner.
  • Participants pay for their resources and also pay for data transfer charges associated with Inter-Availability Zone data transfer, internet gateway, VPC peering connections, and data transfer through an AWS Direct Connect.
• Things to know

  • VPC owners pay hourly charges (where applicable), data processing and data transfer charges across NAT gateways, virtual private gateways, transit gateways, AWS PrivateLink, and VPC endpoints.
  • Currently few services cannot use shared subnets.
• How do I allow my Lambda function access to my Amazon S3 bucket?

  Important: If your S3 bucket and the functions IAM role are in different accounts, then you must also grant the required permissions on the S3 bucket policy. 
• CloudFront standard logs and real-time logs

  CloudFront logs provide detailed records about requests that are made to a distribution. These logs are useful for many applications.

  Edge function logs

  Logs generated by edge functions, both CloudFront Functions and Lambda@Edge, are sent directly to Amazon CloudWatch Logs and are not stored anywhere by CloudFront. CloudFront Functions uses an AWS Identity and Access Management (IAM) service-linked role to send customer-generated logs directly to CloudWatch Logs in your account.
• CloudFront console reports

  • The CloudFront console includes a variety of reports, including the cache statistics report, the popular objects report, and the top referrers report. Most CloudFront console reports are based on the data in CloudFront access logs, which contain detailed information about every user request that CloudFront receives. However, you don't need to enable access logs to view the reports.
• The top three most important AWS WAF rate-based rules are:

  • A blanket rate-based rule to protect your application from large HTTP floods.
  • A rate-based rule to protect specific URIs at more restrictive rates than the blanket rate-based rule.
  • A rate-based rule to protect your application against known malicious source IPs.
• Example to Determine Rate-based Rules

  1. An application user makes requests to the application.
  2. AWS WAF captures information about the incoming requests and sends this to Amazon Kinesis Data Firehose.
  3. Kinesis Data Firehose delivers the logs to an Amazon Simple Storage Service (Amazon S3) bucket, where they will be stored.
  4. The operations team uses Amazon Athena to analyze the logs with SQL queries.
  5. Athena queries the logs in the S3 bucket and shows the query results.
  6. The operations team uses the query results to determine the appropriate AWS WAF rate-based rule.
• Blanket rate-based rule

  • A blanket rate-based rule is designed to prevent any single source IP address from negatively impacting the availability of a website. For example, if the threshold for the rate-based rule is set to 2,000, the rule will block all IPs that are making more than 2,000 requests in a rolling 5-minute period. This is the most basic rate-based rule, and one of the most valuable for AWS WAF customers to implement.