A three-tier VPC with SSH open to the world

Which is more urgent: the AK/SK. Port 22 open to 0.0.0.0/0 with a shared password is a serious exposure and will be brute-forced continuously, but it requires an attacker to succeed at authentication. A credential committed to a configuration file on 8 internet-facing hosts, with a bucket policy already public on one prefix, is a live credential that may already be in use. Treat it as potentially compromised: disable the key pair immediately, issue a new one, and pull CTS logs for OBS and IAM activity around the rotation to see whether it has been used from unexpected source IPs. Then move the application to an IAM agency (委托) attached to the ECS instances, so the application obtains temporary credentials from the instance metadata service and no long-lived secret exists in configuration at all. Finally, narrow the bucket policy from public-read on a prefix to a signed-URL or CDN-origin pattern for the marketing site.

SSH containment, same day. Remove the 0.0.0.0/0 rule on port 22 from the web tier security group. Restrict it to the corporate egress range. Replace the shared password with key-based authentication and individual accounts.

Target design. A dedicated bastion - either a hardened jump-host ECS in the public subnet with a security group allowing 22 only from the corporate egress range plus MFA, or the managed Cloud Bastion Host service, which provides session recording and per-user authorisation without you operating the host. Session recording is not a nicety: with a shared password there is currently no way to attribute an action to a person. Private-subnet instances should have no inbound internet path at all, and administrative access should be brokered through the bastion.

What the contractor needs: read objects under one prefix for 30 days, and nothing else. The design should make the access expire on its own rather than depend on someone remembering.

Option 1 - a bucket ACL or bucket policy granting anonymous read. Rejected outright. It is not time-bound, it cannot be attributed to a person, and it grants access to anyone who learns the URL, not to the contractor.

Option 2 - sharing the application's credentials. Rejected. This is how the current AK/SK problem becomes a second incident, and it destroys attribution.

Option 3 - an IAM user with a least-privilege custom policy. This is the practical answer. Create a dedicated IAM user for the contractor, attach a custom policy scoped to obs:GetObject and obs:ListBucket on the specific bucket and prefix only - no obs:*, no bucket-level administration - enable MFA, and put a calendar-bound deactivation on day 30. Add a condition restricting source IP to the contractor's office range using the source-IP condition key. Every action lands in CTS with the contractor's identity attached.

Option 4 - temporary credentials via STS. Cleaner in principle because the credentials expire without human action, but STS tokens are intentionally short-lived and would need a renewal path across 30 days. If the contractor's tooling can refresh them, this is the better answer; if not, Option 3 with a hard expiry date is acceptable.

Either way: log the grant, log the expiry, and review CTS access logs at day 30 to confirm the contractor read only what was expected. The measure of success is not just that access ended, but that you can prove what was accessed while it was live.

Web tier: inbound 80/443 from 0.0.0.0/0 is correct - that is what a public-facing load-balanced tier is for, and WAF sits in front. The port 22 rule is the defect, already addressed. What is missing is outbound control: the default egress rule usually permits all, so a compromised web instance can reach anything, including the internet, for command-and-control or exfiltration. Restrict egress to the app tier, OBS endpoints and update repositories.

Application tier: allow all from 10.0.1.0/24 is too permissive. It grants every protocol and every port to every host in the web subnet. If a single web instance is compromised, it can reach any service the app tier exposes on any port. Narrow it to the specific ports the application actually uses.

Data tier: 3306 from 10.0.0.0/16 is the real break. That range covers the entire VPC, so the web tier - the tier an attacker reaches first - can open a MySQL connection directly to the database, bypassing the application tier entirely. It also covers any future subnet added to the VPC. Restrict it to 10.0.2.0/24 on 3306 only. This single change is worth more than the rest combined, because it removes the shortest path from the internet to the data.

What I would add. A network ACL on the data subnet as a coarse second layer: security groups are stateful, instance-attached and allow-only, whereas ACLs are stateless, subnet-scoped and can deny explicitly. Use the ACL to deny anything that is not the app tier, so a misconfigured security group does not reopen the path. Also note that a security group cannot deny - every rule is an allow, and evaluation is the union across all groups attached to the instance, so a permissive rule in any attached group silently widens the effective policy.

Verify, do not assume. Use the VPC traffic-path or connection-check tooling to confirm that a web instance can no longer reach 10.0.3.x:3306 after the change.