Create a Private S3 Bucket with Buckets and Verify Its Settings in AWS

Introduction

Creating an S3 bucket is only part of the setup. You also need to verify that its configuration matches the settings you selected.

In this tutorial, I use Buckets by Serverless Creed to create a disposable private S3 bucket with versioning, Amazon S3-managed encryption (SSE-S3), and Block Public Access enabled. I then compare the selected settings with the configuration in AWS.

The walkthrough also explains bucket-list refresh, the empty-bucket view, and recovery from denied access-control requests. A supplementary run verifies Object Ownership and records both bucket-level and account-level Block Public Access settings.

Prerequisites and tested environment

Before following the walkthrough, you will need:

• Buckets installed on your computer. The installer is available from the official download page.
• An approved AWS sandbox and an authorized profile for bucket creation, configuration checks, and cleanup.
• AWS Console access to independently verify the bucket settings.
• A separate approved restricted profile for the permission-denied example.
• A unique disposable bucket name and an approved AWS Region.

Use your assigned sandbox permissions rather than granting yourself general administrator access.

The evidence comes from separate documented tests on Windows in us-east-1, followed by a supplementary run using Buckets 2.7.47:

Part of the walkthrough	Recorded application version
Private bucket creation	2.7.9
Bucket-list refresh and empty-state checks	2.7.12
Historical denied CORS write	2.7.17
Supplementary creation, verification, empty view and denied reads	2.7.47

The historical tests used different disposable buckets. The supplementary run used one fresh bucket for the creation, empty view, AWS configuration checks and restricted-profile checks. Historical screenshots are labelled separately; they do not represent one continuous execution on a single build. Interface labels may differ between versions.
The supplementary work was performed on 6–7 October 2026 (India Standard Time). Its authorized profile was named aws-admin; older records use the profile name default. A profile name identifies a local configuration, so verify the account and identity rather than relying on the name alone. Private approval and account details belong in the supporting evidence record.

1. Choose the bucket settings

Before creating the bucket, decide which settings you intend to apply. For this test, I used the following configuration:

Setting	Selected value
AWS Region	us-east-1
Object Versioning	Enabled
Default encryption	Amazon S3-managed encryption (SSE-S3)
Block All Public Access	Enabled
Object Lock	Disabled
Static Website Hosting	Disabled

Versioning retains multiple versions of objects. SSE-S3 provides encryption at rest, while Block Public Access restricts public access through policies and ACLs. These controls serve different purposes: encryption does not grant access, and versioning does not prevent every form of deletion.

Object Ownership is checked separately in AWS. Only describe it as an application selection if that control is actually available in the tested form.

2. Create the bucket in Buckets

Open the bucket-creation form in Buckets and select the authorized AWS profile. Enter a unique bucket name, choose the approved Region, and select the configuration listed above.

For my recorded creation test, I used the default profile and a disposable bucket in us-east-1. I enabled Object Versioning, SSE-S3 encryption, and Block All Public Access, while leaving Object Lock and Static Website Hosting disabled.

Review the name, Region, and selected options before confirming creation.

Figure 1. Bucket-creation form showing the disposable bucket name, Region and selected options before confirmation.

After confirming, follow the operation through its creation stages. A bucket appearing in the list does not, by itself, prove that every selected setting was applied.

In my recorded test, creation completed without an observed error or partial-failure message. I reopened the bucket’s properties in Buckets, where Versioning appeared as Enabled and Public access appeared as Fully blocked.

These application values were an initial check. I then verified the configuration independently in AWS.

After creation, Buckets displayed Versioning as Enabled and Public access as Fully blocked.

3. Verify the bucket settings in AWS

After checking the bucket’s properties in Buckets, open the same bucket in AWS Console. Confirm its name and Region before inspecting the configuration.

Check Bucket Versioning and Default encryption under Properties, then check Block Public Access and Object Ownership under Permissions.

My recorded creation test documented the following AWS results:

Setting	Selected in Buckets	Recorded AWS result
Region	us-east-1	us-east-1
Bucket Versioning	Enabled	Enabled
Default encryption	SSE-S3	Server-side encryption with Amazon S3 managed keys
Block All Public Access	Enabled	On; all four individual flags enabled

AWS Console verification of SSE-S3 default encryption.

AWS Console verification of enabled bucket versioning.

AWS Console verification of all four bucket-level public-access blocks

These checks confirm the recorded configuration, rather than providing an absolute security guarantee. Versioning, encryption and access controls serve different purposes, and the bucket’s access also depends on applicable policies and account-level restrictions.

The documented AWS values matched the selected configuration. If a value differs, record the mismatch rather than treating the operation as fully successful.

Object Ownership and account-level checks in the supplementary run

In the supplementary 2.7.47 run, AWS Console showed versioning Enabled, default encryption SSE-S3, and all four bucket-level Block Public Access flags On. AWS also showed Bucket owner enforced Object Ownership, with ACLs disabled. Ownership was independently verified in AWS; I do not describe it as an option selected in Buckets.

Setting or check	Intended value / source	Observed result in the supplementary run
Region	us-east-1	us-east-1 shown in Buckets
Versioning	Enabled	Enabled in AWS Console
Default encryption	SSE-S3	Amazon S3 managed keys in AWS Console
Bucket-level Block Public Access	All four flags enabled	All four flags On in AWS Console
Object Ownership	Independently inspect AWS state	Bucket owner enforced; ACLs disabled
Account-level Block Public Access	Inspect existing settings without changing them	All four settings Off

Supplementary run: AWS Console shows Bucket owner enforced ownership and disabled ACLs.

All four account-level Block Public Access settings were Off at the time of inspection; no account settings were changed.

Account-level settings being Off does not automatically grant public access. S3 applies the most restrictive combination of applicable bucket, account and organization settings. In this fixture, the bucket-level flags remained On. See AWS documentation on Block Public Access.

With Bucket owner enforced, ACLs are disabled. The Access Control ACL tab displayed that ownership state. This is different from an IAM permission-denied response; I did not enable ACLs for the test.

4. Refresh the bucket list

Refresh the bucket list under the same authorized AWS profile, then locate and open your bucket.

In a separate supporting Buckets version 2.7.12 on Windows, I created a disposable bucket directly in AWS Console. It did not initially appear in Buckets. Selecting Refresh Bucket List made it visible.

After deleting that test bucket through AWS Console, its entry remained visible in Buckets until I refreshed again. Refreshing removed the stale entry. This demonstrates why the displayed list should be refreshed after changes made outside the application.

The bucket created in AWS Console appeared in Buckets after refreshing the list

Refreshing after AWS-side deletion removed the test bucket from the list

5. Inspect the empty-bucket view

Open the bucket under the authorized AWS profile and inspect its object list.

In a separate supporting test on Windows version 2.7.12 and supplementary run using Buckets 2.7.47 on Windows, I opened an empty disposable bucket. Buckets displayed Create Folder and Upload Files actions, providing clear next steps for adding content.

Keep the bucket empty while capturing this part of the walkthrough. A failed or access-denied request does not prove that a bucket is empty; confirm that the object-list request completed successfully.

Separate empty-state test: an empty bucket displays Create Folder and Upload Files actions.

6. Handle denied access-control requests

A restricted AWS profile may be prevented from reading security settings, changing them, or both. The following tests demonstrate these differences.

Restricted-profile checks in Buckets 2.7.47

In the supplementary test using Buckets 2.7.47 on Windows, I used a separate temporary profile named tcacl006-restricted. It allowed bucket listing and basic reads of the disposable test bucket, while explicitly denying access to its security configuration.

Under this profile, I opened Access Control and checked the available tabs.

Tab	Observed result
Bucket Policy	Loading failed with an explicit deny for s3:GetBucketPolicy
Public Access	Loading failed with an explicit deny for s3:GetBucketPublicAccessBlock
CORS	Loading failed with an explicit deny for s3:GetBucketCORS

The restricted profile could not load Public Access settings because its identity policy explicitly denied s3:GetBucketPublicAccessBlock.

The Access Control dialog remained usable: I could switch tabs and close it after the errors.

The ACL tab displayed “ACLs disabled — Bucket owner enforced.” This was an ownership-related restriction, rather than a displayed IAM authorization error. I did not enable ACLs or change Object Ownership.

Because the Public Access settings failed to load, the tab did not display editable flags or a Save control. Resubmitting the existing Public Access Block values was therefore unavailable in this UI state. This test demonstrates denied configuration reads, rather than a denied PAB save.

Recover using the authorized profile

I closed the dialog, switched to the authorized aws-admin profile, and reopened Access Control for the same bucket.

The Public Access tab loaded successfully with all four blocking flags checked. The CORS tab displayed an empty configuration, [].

After switching to the authorized profile, the same bucket’s Public Access settings loaded with all four blocking flags checked.

I then completed an independent AWS Console check before cleanup to confirm that the intended configuration remained unchanged.

Recovery used the existing authorized profile. It did not require broadening the restricted profile’s permissions or weakening public-access controls.

Historical example: a denied CORS write in Buckets 2.7.17

An earlier, separate supporting test used Buckets 2.7.17 on Windows and a different disposable bucket. In that test, the restricted profile could read configuration, while security-configuration writes were restricted. The authorized profile was named default.

Under the restricted profile, I opened Access Control → CORS. The application initially displayed an empty configuration, [].

I attempted to save this test configuration:

[
  {
    "AllowedOrigins": ["https://example.invalid"],
    "AllowedMethods": ["GET"]
  }
]

AWS rejected the save. Buckets displayed an authorization error identifying s3:PutBucketCORS and an explicit deny in the restricted identity’s policy. The Access Control dialog remained usable.

Historical test on Buckets 2.7.17: AWS rejected the restricted profile’s CORS write with an explicit deny for s3:PutBucketCORS.

Verify that the denied CORS change was not applied

After the failed save, I closed and reopened the CORS section. It again displayed [].

I independently checked the bucket using the authorized default profile. The following command illustrates that verification; replace the example bucket and profile names with your approved test values:

aws s3api get-bucket-cors --bucket EXAMPLE_BUCKET --profile AUTHORIZED_PROFILE

AWS returned NoSuchCORSConfiguration, confirming that no CORS configuration existed after the denied save. Together with the initial empty configuration, this supported the conclusion that the attempted change was not applied.

Historical test: an independent check using the authorized default profile returned NoSuchCORSConfiguration after the denied save.

The historical test demonstrates a denied write. The supplementary 2.7.47 test demonstrates denied reads and successful configuration loading after returning to the authorized profile. They are separate tests with different permission settings.

7. Clean up the disposable resources

After retaining the evidence, remove only the disposable resources created for the walkthrough.

For the historical creation test, my cleanup record states that the bucket was empty and was deleted after evidence collection. For the separate empty-state test, I removed the uploaded test object and folder before deleting its bucket.

The historical permissions-test cleanup removed the temporary restricted IAM identity, access key, profile and associated test policy. The authorized default profile remained unchanged.

For the supplementary test using Buckets 2.7.47, I completed the final AWS configuration check and deleted the disposable bucket and temporary restricted IAM user after collecting evidence.

For your own cleanup:

1. Confirm that the bucket is the disposable resource you are authorized to remove.
2. Remove any test objects. If versioning is enabled and objects were uploaded, remove all created versions and delete markers as authorized.
3. Delete the disposable bucket.
4. Refresh the lists in AWS Console and Buckets to verify that the bucket is absent, rather than merely empty.
5. Remove the temporary restricted identity, its access keys and test policy. Remove any remaining local or application profile entries and temporary credential files.

Preserve shared resources and retain the final configuration checks and cleanup evidence with the test record.

8. Tested scope and limitations

This article combines historical Windows tests using Buckets versions 2.7.9, 2.7.12 and 2.7.17 with a supplementary test using version 2.7.47.

The historical tests used different disposable buckets. The supplementary test used one fresh bucket for creation, the empty-bucket view, AWS configuration verification and restricted-profile checks. The labelled screenshots should therefore be read in their respective test contexts.

The supplementary AWS verification showed:

• Bucket Versioning enabled.
• SSE-S3 default encryption.
• All four bucket-level Block Public Access flags enabled.
• Bucket owner enforced Object Ownership, with ACLs disabled.
• All four account-level Block Public Access settings disabled at the time of inspection.

Object Ownership was independently verified in AWS; it is not presented as an option selected in the Buckets creation form. Account-level settings were inspected without modification. Their disabled state does not automatically grant public access: S3 applies the most restrictive combination of applicable public-access blocking settings.

The historical permissions example demonstrates a denied CORS write and subsequent verification that the change was not applied. The supplementary example demonstrates denied bucket-policy, Public Access Block and CORS reads, followed by successful loading through the authorized profile.

The ACL tab displayed ownership-related restrictions rather than an ACL permission-denied error. A PAB save attempt was unavailable because the restricted profile could not load the settings and the tab did not expose a Save control.

These observations describe the tested configurations and operations. They do not provide an absolute security guarantee or establish every possible access path or behaviour in other application versions.