Amazon Comprehend for advanced text analytics now includes Custom Classification.
Introducing Amazon S3 Block Public Access – another layer of protection for your accounts and buckets
With the introduction of Amazon S3 Block Public Access, securing your S3 data has never been easier. With a few clicks in the S3 management console, you can apply S3 Block Public Access to every bucket in your account – both existing and any new buckets created in the future – and make sure that there is no public access to any object. By default, new S3 bucket settings do not allow public access, but customers can modify these settings to grant public access using policies or object-level permissions. The Amazon S3 Block Public Access settings override S3 permissions that allow public access, making it easy for the account administrator to set up a centralized control to prevent variation in security configuration regardless of how an object is added or a bucket is created. These settings are auditable, providing a further layer of control, using AWS Trusted Advisor bucket permission checks, AWS CloudTrail logs, Amazon Macie and Amazon CloudWatch.
Easily Tag Secrets and Configure Rotation of Secrets from the Secrets Manager Console
AWS Secrets Manager makes it easier to follow the security best practice of using short-term secrets by rotating secrets safely on a schedule that you determine. For example, you can configure Secrets Manager to rotate a database credential daily, turning a typical, long-term secret in to a short-term secret that is rotated automatically. Now, Secrets Manager makes it easier for you to manage and rotate secrets by introducing three enhancements to the Secrets Manager console . First, you can tag secrets from the console. Second, you can give the rotation Lambda function a custom name. Finally, you can use existing Lambda functions to rotate new secrets.
Deploy AWS IoT Camera Connector on AWS with New Quick Start
This Quick Start builds an Internet of Things (IoT) Camera Connector environment and serverless architecture on the Amazon Web Services (AWS) Cloud in about 5 minutes.
Amazon Aurora Serverless Now Available in Additional Regions
Amazon Aurora Serverless (MySQL compatible edition) is now available in an additional 9 AWS Regions. With the additions of Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), US West (N. California), Canada (Central), EU (Frankfurt), EU (London), and EU (Paris), you can now choose the Serverless configuration of Amazon Aurora in 14 geographic Regions.
Amazon RDS Automated Backups Can Now Be Retained After Database Deletion
You can now retain Amazon RDS automated backups (system snapshots and transaction logs) when you delete a database instance. This allows you to restore a deleted database instance to a specified point in time within the backup retention period even after it has been deleted, protecting you against accidental deletion of data.
AWS Lambda Doubles Payload Size for Asynchronous Invocations
The maximum payload size for asynchronous AWS Lambda functions is now 256KB. Previously, the limit was 128KB. Lambda supports multiple invocation modes today. Now, you can pass larger payloads when a function is invoked asynchronously, allowing Lambda to operate more seamlessly with services like SNS that already support larger payloads. Read our documentation to learn more about the asynchronous invocation type.
Synchronously Provision Instances with Amazon EC2 Fleet
Amazon EC2 Fleet now supports a new request type, Instant, that lets you provision capacity synchronously across instance types, Availability Zones (AZs) and purchase models. The CreateFleet API will return the instances launched in the API response with the “Instant” request type. EC2 Fleet now offers 3 request types: instant, request, and maintain, that can be used to indicate whether EC2 Fleet should return instance information synchronously, launch instances asynchronously until the fleet reaches your desired capacity, or attempt to maintain your desired capacity.
When you set your fleet type to “Instant” you can rely on a synchronous API response, providing instance details including instance id, instance type and subnet rather than describing a fleet ID. When using Instant type fleets EC2 Fleet will not attempt to replenish instances if interrupted. Following the create-fleet synchronous response EC2 Fleet will take no further action enabling you to control if and when instances are launched.
Amazon EC2 Fleet is a feature that simplifies the provisioning of large amounts of EC2 capacity, including provisioning across different EC2 instance types, Availability Zones and across On-Demand, Reserved and Spot purchasing models. With a single API call, you can provision capacity that delivers the best mix of instance types and purchasing models to achieve your desired performance and cost. To learn more about EC2 Fleet, read the FAQs .
Amazon ECS Now Allows Two Additional Docker Flags
You can now specify two new docker flags as parameters in your Amazon Elastic Container Service (ECS) Task Definition. These flags are pidMode and ipcMode.
The pidMode parameter allows you to configure your containers to share their process ID (PID) namespace with other containers in the task, or with the host. Sharing the PID namespace enables for example monitoring applications deployed as containers to access information about other applications running in the same task or host.
The ipcMode parameter allows you to configure your containers to share their inter-process communication (IPC) namespace with the other containers in the task, or with the host. The IPC namespace allows containers to communicate directly through shared-memory with other containers running in the same task or host.
This feature is currently supported with EC2 launch-type. For more information about using Docker parameters in task definitions, visit the Amazon ECS documentation .
To view where Amazon ECS is avaiable, please visit our region table .
Announcing Support for DNS Resolution over Inter-Region VPC Peering
Today, we are announcing support for Domain Name System (DNS) resolution over Inter-Region Virtual Private Cloud (VPC) Peering. You can now resolve DNS hostnames to private IP addresses when queried from a peered VPC in another AWS Region. Using DNS names to access resources makes application development and management simpler and less error-prone. By using DNS resolution over Inter-Region VPC Peering, resources in peered VPCs in another AWS Region are always accessed over the Inter-Region VPC Peering connection.
Inter-Region VPC Peering allows VPC resources running in different AWS Regions, such as EC2 instances, RDS databases, and Lambda functions, to communicate with each other using private IP addresses, without requiring gateways, VPN connections, or separate network appliances. Built on the same scalable, redundant, and highly available technology that powers VPCs today, Inter-Region VPC Peering encrypts inter-region traffic with no single point of failure or bandwidth bottleneck. Traffic using Inter-Region VPC Peering always stays on the AWS global network and never traverses the public internet. This approach reduces the attack surface to threat vectors, such as common exploits and DDoS attacks.
You can enable DNS resolution for Inter-Region VPC Peering using the AWS Management Console or the AWS Command Line Interface (CLI). For more information, see DNS Resolution Support for Peering Connections .
For more information on VPC Peering, see our documentation .