S3 bucket can limit access from public IPs using AWS:SourceIP.
If an object is KMS encrypted, make sure that the KMS key policy grants permissions to the IAM user for the following actions:
Object Lifecycle Management
To manage your objects so that they are stored cost effectively throughout their lifecycle, configure their Amazon S3 Lifecycle. An S3 Lifecycle configuration is a set of rules that define actions that Amazon S3 applies to a group of objects. There are two types of actions:
- Transition actions—Define when objects transition to another storage class. For example, you might choose to transition objects to the S3 Standard-IA storage class 30 days after you created them, or archive objects to the S3 Glacier storage class one year after creating them.There are costs associated with the lifecycle transition requests.
- Expiration actions—Define when objects expire. Amazon S3 deletes expired objects on your behalf.The lifecycle expiration costs depend on when you choose to expire objects.
Note: Make sure you understand the supported transitions for the exam.
Restricting Public Access
The Amazon S3 Block Public Access feature provides settings for access points, buckets, and accounts to help you manage public access to Amazon S3 resources.
By default, new buckets, access points, and objects don’t allow public access.
However, users can modify bucket policies, access point policies, or object permissions to allow public access. S3 Block Public Access settings override these policies and permissions so that you can limit public access to these resources.
The following settings are available:
- IgnorePublicAcls – Setting this option to
TRUEcauses Amazon S3 to ignore all public ACLs on a bucket and any objects that it contains.
- BlockPublicAcls – PUT bucket ACL and PUT objects requests are blocked if granting public access.
- BlockPublicPolicy – Rejects requests to PUT a bucket policy if granting public access.
- RestrictPublicBuckets – Restricts access to principles in the bucket owners’ AWS account.
- General purpose for latency sensitive use cases.
- Max I/O – higher latency, higher throughput, highly parallel.
- Bursting mode – bursts of activity
- Provisioned IO – high throughput to storage ratio.
For on-premise access use DX or VPN and access by private IP (not DNS).
Amazon FSx for Lustre
Managed Lustre filesystem.
Designed for HPC Linux clients (POSIX).
Hundreds GB/s throughput and sub millisecond latency.
Can be deployed in persistent or scratch.
Accessible over VPN and Direct Connect.
Can backup to S3 – manual or automatic (0-35 day retention).
Metadata stored on Metadata Targets (MST).
Performance is based on the size of the filesystem.
Scratch is designed for best performance for short term or temporary use cases.
Does not provide HA or replication.
Larger files systems require more servers and disks (more chance of failure).
Auto heals when hardware failure occurs.
Min size is 1.2 TiB with increments of 2.4 TiB.
Longer term use cases.
Provides HA in one AZ and self-healing.
50 MB/s, 100 MB/s, and 200 MB/s per TiB of storage.
Burst up to 1,300 Mb/s per TiB (uses a credit system).
Baseline I/O performance for General Purpose SSD storage is 3 IOPS for each GiB, with a minimum of 100 IOPS. This relationship means that larger volumes have better performance.
When using General Purpose SSD storage, a DB instance receives an initial I/O credit balance of 5.4 million I/O credits.
This initial credit balance is enough to sustain a burst performance of 3,000 IOPS for 30 minutes.
This balance is designed to provide a fast initial boot cycle for boot volumes and to provide a good bootstrapping experience for other applications.
Volumes earn I/O credits at the baseline performance rate of 3 IOPS for each GiB of volume size. For example, a 100-GiB SSD volume has a baseline performance of 300 IOPS.